Nobody. The comment is wrong.
Possibly the code is wrong, too. We don't want to keep scanning
the same page all the time.
> 2) Is the locked page worth waiting for? I can understand that the page is being
> laundered so after wait we may get a clean page but from performance
> point of view this is involving unnecessary context switches. Also during
> high memory pressure kswapd shall sleep here when it can get more
> clean pages on the inactive list ? What are we loosing if we don't wait on
> the page and believe that in next pass we shall free this page
>
Well we need to wait on I/O _somewhere_ in there. Otherwise everyone
just ends up busywaiting on IO completion. The idea is that on the
first pass through the inactive list, we start I/O, mark the page as
PG_Launder and don't wait on the I/O. On the second pass through the
list, when we find a PG_Launder page, we wait on it. This has the
effect of slowing memory-requesters down to the speed of the I/O
system. All this is for mmapped pages. The same behaviour is
implemented for write() pages via the BH_Launder bits on its buffers
over in sync_page_buffers().
-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/