lkml.org 
[lkml]   [2001]   [Dec]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: locked page handling
Date
On December 31, 2001 08:37 pm, Andrew Morton wrote:
> 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().

I think we want the pages in process of being written to live on a separate
list. Pages can be pulled of that list by a separate thread, or perhaps in
the IO completion interrupt (opportunistically, if the list lock is available)
meaning kswapd would block less and waste less time examining locked pages.

--
Daniel
-
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/

\
 
 \ /
  Last update: 2005-03-22 13:14    [W:0.048 / U:25.288 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site