Re: locked page handling

[Andrew Morton <akpm@zip.com.au>]

alad@hss.hns.com wrote:
> 
> In 2.4.16, vmscan.c::shrink_cache(), we have following piece of code -
> 
>           /*
>            * The page is locked. IO in progress?
>            * Move it to the back of the list.
>            */
>           if (unlikely(TryLockPage(page))) {
>                if (PageLaunder(page) && (gfp_mask & __GFP_FS)) {
>                     page_cache_get(page);
>                     spin_unlock(&pagemap_lru_lock);
>                     wait_on_page(page);
>                     page_cache_release(page);
>                     spin_lock(&pagemap_lru_lock);
>                }
>                continue;
>           }
> 
> 1) Who is moving the page the back of list ?

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().

-