Drop PageReclaim()

Drop PageReclaim()

[Christoph Lameter]

Am I missing something here? I cannot see PageReclaim have any effect?



PageReclaim is only used for dead code. The only current user is
end_page_writeback() which has the following lines:

 if (!TestClearPageReclaim(page) || rotate_reclaimable_page(page)) {
         if (!test_clear_page_writeback(page))
                  BUG();
 }

So the if statement is performed if !PageReclaim(page).
If PageReclaim is set then we call rorate_reclaimable(page) which
does:

 if (!PageLRU(page))
       return 1;

The only user of PageReclaim is shrink_list(). The pages processed
by shrink_list have earlier been taken off the LRU. So !PageLRU is always 
true.

The if statement is therefore always true and the rotating code
is never executed.

So drop all the PageReclaim() stuff. This yields one free
page state flag that we need for PageMlocked().

Signed-off-by: Christoph Lameter <clameter@sgi.com>

Index: current/mm/page_io.c
===================================================================
--- current.orig/mm/page_io.c	2007-02-07 00:16:20.000000000 -0800
+++ current/mm/page_io.c	2007-02-07 00:18:47.000000000 -0800
@@ -67,7 +67,6 @@ static int end_swap_bio_write(struct bio
 				imajor(bio->bi_bdev->bd_inode),
 				iminor(bio->bi_bdev->bd_inode),
 				(unsigned long long)bio->bi_sector);
-		ClearPageReclaim(page);
 	}
 	end_page_writeback(page);
 	bio_put(bio);
Index: current/mm/swap.c
===================================================================
--- current.orig/mm/swap.c	2007-02-07 00:16:20.000000000 -0800
+++ current/mm/swap.c	2007-02-07 00:18:47.000000000 -0800
@@ -95,47 +95,6 @@ void put_pages_list(struct list_head *pa
 EXPORT_SYMBOL(put_pages_list);
 
 /*
- * Writeback is about to end against a page which has been marked for immediate
- * reclaim.  If it still appears to be reclaimable, move it to the tail of the
- * inactive list.  The page still has PageWriteback set, which will pin it.
- *
- * We don't expect many pages to come through here, so don't bother batching
- * things up.
- *
- * To avoid placing the page at the tail of the LRU while PG_writeback is still
- * set, this function will clear PG_writeback before performing the page
- * motion.  Do that inside the lru lock because once PG_writeback is cleared
- * we may not touch the page.
- *
- * Returns zero if it cleared PG_writeback.
- */
-int rotate_reclaimable_page(struct page *page)
-{
-	struct zone *zone;
-	unsigned long flags;
-
-	if (PageLocked(page))
-		return 1;
-	if (PageDirty(page))
-		return 1;
-	if (PageActive(page))
-		return 1;
-	if (!PageLRU(page))
-		return 1;
-
-	zone = page_zone(page);
-	spin_lock_irqsave(&zone->lru_lock, flags);
-	if (PageLRU(page) && !PageActive(page)) {
-		list_move_tail(&page->lru, &zone->inactive_list);
-		__count_vm_event(PGROTATED);
-	}
-	if (!test_clear_page_writeback(page))
-		BUG();
-	spin_unlock_irqrestore(&zone->lru_lock, flags);
-	return 0;
-}
-
-/*
  * FIXME: speed this up?
  */
 void fastcall activate_page(struct page *page)
Index: current/mm/vmscan.c
===================================================================
--- current.orig/mm/vmscan.c	2007-02-07 00:16:20.000000000 -0800
+++ current/mm/vmscan.c	2007-02-07 00:18:51.000000000 -0800
@@ -366,18 +366,11 @@ static pageout_t pageout(struct page *pa
 			.for_reclaim = 1,
 		};
 
-		SetPageReclaim(page);
 		res = mapping->a_ops->writepage(page, &wbc);
 		if (res < 0)
 			handle_write_error(mapping, page, res);
-		if (res == AOP_WRITEPAGE_ACTIVATE) {
-			ClearPageReclaim(page);
+		if (res == AOP_WRITEPAGE_ACTIVATE)
 			return PAGE_ACTIVATE;
-		}
-		if (!PageWriteback(page)) {
-			/* synchronous write or broken a_ops? */
-			ClearPageReclaim(page);
-		}
 		inc_zone_page_state(page, NR_VMSCAN_WRITE);
 		return PAGE_SUCCESS;
 	}
Index: current/include/linux/swap.h
===================================================================
--- current.orig/include/linux/swap.h	2007-02-07 00:18:39.000000000 -0800
+++ current/include/linux/swap.h	2007-02-07 00:18:55.000000000 -0800
@@ -185,7 +185,6 @@ extern void FASTCALL(activate_page(struc
 extern void FASTCALL(mark_page_accessed(struct page *));
 extern void lru_add_drain(void);
 extern int lru_add_drain_all(void);
-extern int rotate_reclaimable_page(struct page *page);
 extern void swap_setup(void);
 
 /* linux/mm/vmscan.c */
Index: current/mm/filemap.c
===================================================================
--- current.orig/mm/filemap.c	2007-02-07 00:18:39.000000000 -0800
+++ current/mm/filemap.c	2007-02-07 00:18:55.000000000 -0800
@@ -530,10 +530,8 @@ EXPORT_SYMBOL(unlock_page);
  */
 void end_page_writeback(struct page *page)
 {
-	if (!TestClearPageReclaim(page) || rotate_reclaimable_page(page)) {
-		if (!test_clear_page_writeback(page))
-			BUG();
-	}
+	if (!test_clear_page_writeback(page))
+		BUG();
 	smp_mb__after_clear_bit();
 	wake_up_page(page, PG_writeback);
 }
Index: current/include/linux/page-flags.h
===================================================================
--- current.orig/include/linux/page-flags.h	2007-02-07 00:24:56.000000000 -0800
+++ current/include/linux/page-flags.h	2007-02-07 00:25:29.000000000 -0800
@@ -30,7 +30,7 @@
  * PG_uptodate tells whether the page's contents is valid.  When a read
  * completes, the page becomes uptodate, unless a disk I/O error happened.
  *
- * PG_referenced, PG_reclaim are used for page reclaim for anonymous and
+ * PG_referenced is used for page reclaim for anonymous and
  * file-backed pagecache (see mm/vmscan.c).
  *
  * PG_error is set to indicate that an I/O error occurred on this page.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: Drop PageReclaim()

[Hugh Dickins]

On Wed, 7 Feb 2007, Christoph Lameter wrote:

> Am I missing something here? I cannot see PageReclaim have any effect?

I think you are missing something.

> 
> PageReclaim is only used for dead code. The only current user is
> end_page_writeback() which has the following lines:
> 
>  if (!TestClearPageReclaim(page) || rotate_reclaimable_page(page)) {
>          if (!test_clear_page_writeback(page))
>                   BUG();
>  }
> 
> So the if statement is performed if !PageReclaim(page).
> If PageReclaim is set then we call rorate_reclaimable(page) which
> does:
> 
>  if (!PageLRU(page))
>        return 1;
> 
> The only user of PageReclaim is shrink_list(). The pages processed
> by shrink_list have earlier been taken off the LRU. So !PageLRU is always 
> true.

On return from shrink_page_list(),
doesn't shrink_inactive_list() put those pages back on the LRU?

Hugh

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: Drop PageReclaim()

[Andrew Morton]

On Wed, 7 Feb 2007 06:13:48 -0800 (PST) Christoph Lameter <clameter@sgi.com> wrote:

> Am I missing something here? I cannot see PageReclaim have any effect?
> 
> 
> 
> PageReclaim is only used for dead code. The only current user is
> end_page_writeback() which has the following lines:
> 
>  if (!TestClearPageReclaim(page) || rotate_reclaimable_page(page)) {
>          if (!test_clear_page_writeback(page))
>                   BUG();
>  }
> 
> So the if statement is performed if !PageReclaim(page).
> If PageReclaim is set then we call rorate_reclaimable(page) which
> does:
> 
>  if (!PageLRU(page))
>        return 1;
> 
> The only user of PageReclaim is shrink_list(). The pages processed
> by shrink_list have earlier been taken off the LRU. So !PageLRU is always 
> true.
> 
> The if statement is therefore always true and the rotating code
> is never executed.

end_page_writeback() is amazingly obscure for such a short function.  For
which I apologise, but on revisit, it's still not obvious how to clean it
up.

It does:

	if (!PageReclaim(page)) {
		clear_page_writeback();
	}
	if (PageRecaim(page)) {
		ClearPageReclaim(page);
		foo = rotate_reclaimable_page(page);
		if (foo == 0) {
			/*
			 * rotate_reclaimable_page has already done
			 * clear_page_writeback()
			 */
		} else {
			clear_page_writeback(page);
		}
	}

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: Drop PageReclaim()

[Christoph Lameter]

On Wed, 7 Feb 2007, Andrew Morton wrote:

> On Wed, 7 Feb 2007 06:13:48 -0800 (PST) Christoph Lameter <clameter@sgi.com> wrote:
> 
> > Am I missing something here? I cannot see PageReclaim have any effect?
> > 
> > 
> > 
> > PageReclaim is only used for dead code. The only current user is
> > end_page_writeback() which has the following lines:
> > 
> >  if (!TestClearPageReclaim(page) || rotate_reclaimable_page(page)) {
> >          if (!test_clear_page_writeback(page))
> >                   BUG();
> >  }
> > 
> > So the if statement is performed if !PageReclaim(page).
> > If PageReclaim is set then we call rorate_reclaimable(page) which
> > does:
> > 
> >  if (!PageLRU(page))
> >        return 1;
> > 
> > The only user of PageReclaim is shrink_list(). The pages processed
> > by shrink_list have earlier been taken off the LRU. So !PageLRU is always 
> > true.
> > 
> > The if statement is therefore always true and the rotating code
> > is never executed.
> 
> end_page_writeback() is amazingly obscure for such a short function.  For
> which I apologise, but on revisit, it's still not obvious how to clean it
> up.
> 
> It does:
> 
> 	if (!PageReclaim(page)) {
> 		clear_page_writeback();

Well it does
   if (!test_clear_page_writeback(page))
                  BUG();

> 	if (PageRecaim(page)) {
> 		ClearPageReclaim(page);
> 		foo = rotate_reclaimable_page(page);

PageReclaim is only used while the page is off the LRU. In that case 
rotate_reclaimable_page is always returning 1. So foo = 1 and 
rotate_reclaimable_page is useless.

> 		if (foo == 0) {

> 			/*
> 			 * rotate_reclaimable_page has already done
> 			 * clear_page_writeback()
> 			 */
> 		} else {
> 			clear_page_writeback(page);

This is also a test_clear ...

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: Drop PageReclaim()

[Christoph Lameter]

On Wed, 7 Feb 2007, Hugh Dickins wrote:

> > The only user of PageReclaim is shrink_list(). The pages processed
> > by shrink_list have earlier been taken off the LRU. So !PageLRU is always 
> > true.
> 
> On return from shrink_page_list(),
> doesn't shrink_inactive_list() put those pages back on the LRU?

Yes but it has cleared PageReclaim by then.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: Drop PageReclaim()

[Christoph Lameter]

On Thu, 8 Feb 2007, Christoph Lameter wrote:

> > On return from shrink_page_list(),
> > doesn't shrink_inactive_list() put those pages back on the LRU?
> 
> Yes but it has cleared PageReclaim by then.

Crap. You are right. If the page is still under writeback then 
PageReclaim remains set and end_page_writeback puts the page onn the 
inactive list. 

Could we put the page on the inactive list in shrink_page_list?

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: Drop PageReclaim()

[Christoph Lameter]

On Thu, 8 Feb 2007, Christoph Lameter wrote:

> Could we put the page on the inactive list in shrink_page_list?

shrink_inactive_list() is the only caller of shrink_page_list(). So the 
page is already on the inactive list. The effect of the code is to move the
page back to the inactive list if it was touched while the page was 
written back. Why would we do this? A write ages the page?

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: Drop PageReclaim()

[Christoph Lameter]

Oh gosh. I hope I finally got my head around this. The page is taken off 
the LRU for writeback then PageReclaim is set and its put back to the 
inactive list when writeback ends. This is different from regular file 
writeback where we leave the page on the LRU.



--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: Drop PageReclaim()

[Andrew Morton]

On Thu, 8 Feb 2007 13:55:22 -0800 (PST)
Christoph Lameter <clameter@sgi.com> wrote:

> Oh gosh. I hope I finally got my head around this. The page is taken off 
> the LRU for writeback then PageReclaim is set and its put back to the 
> inactive list when writeback ends. This is different from regular file 
> writeback where we leave the page on the LRU.
> 

No, the page remains on the LRU while it's under writeback.

It goes like this:

During the vmscan we encounter a page at the tail of the inactive list
which we want to reclaim, but it's dirty.  So we start writeout and then
move it to the head of the inactive list and keep scanning.

When writeback completes, we take a look at the page to see if it still
seems to be reclaimable and if so, move it to the tail of the inactive list
so that it will be reclaimed very soon.

PG_reclaim is used to indicate pages which need this treatment.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: Drop PageReclaim()

[Christoph Lameter]

On Thu, 8 Feb 2007, Andrew Morton wrote:

> During the vmscan we encounter a page at the tail of the inactive list
> which we want to reclaim, but it's dirty.  So we start writeout and then
> move it to the head of the inactive list and keep scanning.
> 
> When writeback completes, we take a look at the page to see if it still
> seems to be reclaimable and if so, move it to the tail of the inactive list
> so that it will be reclaimed very soon.

Still reclaimable means on the LRU and not activated?
 
> PG_reclaim is used to indicate pages which need this treatment.

We have a mechanism to trigger events based on the end of writeback 
(also triggered in end_page_writeback). But I guess we are not using it 
because we do not have a process context?

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: Drop PageReclaim()

[Andrew Morton]

On Thu, 8 Feb 2007 14:14:39 -0800 (PST)
Christoph Lameter <clameter@sgi.com> wrote:

> On Thu, 8 Feb 2007, Andrew Morton wrote:
> 
> > During the vmscan we encounter a page at the tail of the inactive list
> > which we want to reclaim, but it's dirty.  So we start writeout and then
> > move it to the head of the inactive list and keep scanning.
> > 
> > When writeback completes, we take a look at the page to see if it still
> > seems to be reclaimable and if so, move it to the tail of the inactive list
> > so that it will be reclaimed very soon.
> 
> Still reclaimable means on the LRU and not activated?

See the tests in rotate_reclaimable_page():

	if (PageLocked(page))
		return 1;
	if (PageDirty(page))
		return 1;
	if (PageActive(page))
		return 1;
	if (!PageLRU(page))
		return 1;

> > PG_reclaim is used to indicate pages which need this treatment.
> 
> We have a mechanism to trigger events based on the end of writeback 
> (also triggered in end_page_writeback).

Not sure what you're referring to there.

> But I guess we are not using it 
> because we do not have a process context?

end_page_writeback() usually runs in hard IRQ context.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: Drop PageReclaim()

[Christoph Lameter]

On Thu, 8 Feb 2007, Andrew Morton wrote:

> > We have a mechanism to trigger events based on the end of writeback 
> > (also triggered in end_page_writeback).
> 
> Not sure what you're referring to there.

      smp_mb__after_clear_bit();
      wake_up_page(page, PG_writeback);

> > But I guess we are not using it 
> > because we do not have a process context?
> 
> end_page_writeback() usually runs in hard IRQ context.

Those sleeping on the page must have their own process context
to do so.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: Drop PageReclaim()

[Andrew Morton]

On Thu, 8 Feb 2007 14:26:48 -0800 (PST)
Christoph Lameter <clameter@sgi.com> wrote:

> On Thu, 8 Feb 2007, Andrew Morton wrote:
> 
> > > We have a mechanism to trigger events based on the end of writeback 
> > > (also triggered in end_page_writeback).
> > 
> > Not sure what you're referring to there.
> 
>       smp_mb__after_clear_bit();
>       wake_up_page(page, PG_writeback);
> 
> > > But I guess we are not using it 
> > > because we do not have a process context?
> > 
> > end_page_writeback() usually runs in hard IRQ context.
> 
> Those sleeping on the page must have their own process context
> to do so.

You've lost me.  I don't see what that sort of thing has to do with
end_page_writeback() and rotate_reclaimable_page().

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: Drop PageReclaim()

[Christoph Lameter]

On Thu, 8 Feb 2007, Andrew Morton wrote:

> > Those sleeping on the page must have their own process context
> > to do so.
> 
> You've lost me.  I don't see what that sort of thing has to do with
> end_page_writeback() and rotate_reclaimable_page().

One could replace the PageReclaim bit with a process waiting on the 
writeback bit to clear. The process would then do the rotation. But that 
would require too many processes.

Hmmm... Does not look as if I can get that bit freed up. It was always a 
mystery to me what the thing did. At least I know now.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: Drop PageReclaim()

[Andrew Morton]

On Thu, 8 Feb 2007 14:40:52 -0800 (PST)
Christoph Lameter <clameter@sgi.com> wrote:

> On Thu, 8 Feb 2007, Andrew Morton wrote:
> 
> > > Those sleeping on the page must have their own process context
> > > to do so.
> > 
> > You've lost me.  I don't see what that sort of thing has to do with
> > end_page_writeback() and rotate_reclaimable_page().
> 
> One could replace the PageReclaim bit with a process waiting on the 
> writeback bit to clear. The process would then do the rotation. But that 
> would require too many processes.

Yeah, we'd need to queue the pages somehow to do that.

> Hmmm... Does not look as if I can get that bit freed up. It was always a 
> mystery to me what the thing did. At least I know now.

well hmm.  Maybe we can just remove PG_reclaim.

The current situation is that we'll rotate a written-back page to the tail
of the inactive list if

	a) the page looks like it'll be reclaimable and
	b) the vm scanner recently encountered that page and wanted to
	   reclaim it.

if we remove PG_reclaim then condition b) just goes away.

I expect that'll be OK for pages which were written back by the vm scanner.
 But it also means that pages which were written back by
pdflush/balance_dirty_pages/fsync/etc will now all also be eligible for
rotation.  ie: the vast majority of written-back pages.

Whether that will make much difference to page aging I don't know.  But it
will cause more lru->lock traffic.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: Drop PageReclaim()

[Christoph Lameter]

On Thu, 8 Feb 2007, Andrew Morton wrote:

> I expect that'll be OK for pages which were written back by the vm scanner.
>  But it also means that pages which were written back by
> pdflush/balance_dirty_pages/fsync/etc will now all also be eligible for
> rotation.  ie: the vast majority of written-back pages.
> 
> Whether that will make much difference to page aging I don't know.  But it
> will cause more lru->lock traffic.

I'd rather avoid more lru lock traffic. Could we simply drop the rotation?
Writeback is typically a relatively long process. The page should 
have made some progress through the inactive list by the time the 
write is complete.

One additional issue that is raised by the writeback pages remaining on 
the LRU lists is that we can get into the same livelock situation as with 
mlocked pages if we keep on skipping over writeback pages. However, the 
system is already slow due to us waiting for I/O. I guess we just do not 
notice.


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: Drop PageReclaim()

[Andrew Morton]

On Thu, 8 Feb 2007 16:22:17 -0800 (PST)
Christoph Lameter <clameter@sgi.com> wrote:

> On Thu, 8 Feb 2007, Andrew Morton wrote:
> 
> > I expect that'll be OK for pages which were written back by the vm scanner.
> >  But it also means that pages which were written back by
> > pdflush/balance_dirty_pages/fsync/etc will now all also be eligible for
> > rotation.  ie: the vast majority of written-back pages.
> > 
> > Whether that will make much difference to page aging I don't know.  But it
> > will cause more lru->lock traffic.
> 
> I'd rather avoid more lru lock traffic. Could we simply drop the rotation?

I doubt it.  One would need to troll five-year-old changelogs and mailing
list discussion, but iirc that rotation was a large win in certain
workloads, preventing scanning meltdowns and general memory stress.

It's probably more useful than tracking mlocked pages, put it that way.

> Writeback is typically a relatively long process. The page should 
> have made some progress through the inactive list by the time the 
> write is complete.

huuuuuuge amounts of testing went into this stuff, on a large number of
machine configurations and workloads.  Plus a few tens of millions of
machine-years in the field.

Possibly we could do it, but it'd be a ton of work in validating the
change.

> One additional issue that is raised by the writeback pages remaining on 
> the LRU lists is that we can get into the same livelock situation as with 
> mlocked pages if we keep on skipping over writeback pages.

That's why we rotate the reclaimable pages back to the head-of-queue.

The vm scanner will throttle twelve times before it fully traverses the
inactive list.  And the extent of that throttling is dependent upon completion of
writeback.  We expect that after a throttled reclaimer has been woken, the
waker has dumped a pile of immediately-reclaimable pages at the tail of
the LRU.

> However, the 
> system is already slow due to us waiting for I/O. I guess we just do not 
> notice.

Well.  IO.  People still seem to thing that vmscan.c is about page
replacement.  It ain't.  Most of the problems in there and most of the work
which has gone into it are IO-related.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: Drop PageReclaim()

[Christoph Lameter]

On Thu, 8 Feb 2007, Andrew Morton wrote:

> I doubt it.  One would need to troll five-year-old changelogs and mailing
> list discussion, but iirc that rotation was a large win in certain
> workloads, preventing scanning meltdowns and general memory stress.

I'd expect trouble here because of the taking of a LRU lock per page. For 
large amounts of concurrent I/O this could be an issue.

> > One additional issue that is raised by the writeback pages remaining on 
> > the LRU lists is that we can get into the same livelock situation as with 
> > mlocked pages if we keep on skipping over writeback pages.
> 
> That's why we rotate the reclaimable pages back to the head-of-queue.

I think the reclaim writeout is one minor contributor here. If there are 
large amounts of writeback pages from f.e. streaming general I/O then we 
may run still into bad situations because we need to scan over them.



--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: Drop PageReclaim()

[Andrew Morton]

On Thu, 8 Feb 2007 17:06:33 -0800 (PST)
Christoph Lameter <clameter@sgi.com> wrote:

> On Thu, 8 Feb 2007, Andrew Morton wrote:
> 
> > I doubt it.  One would need to troll five-year-old changelogs and mailing
> > list discussion, but iirc that rotation was a large win in certain
> > workloads, preventing scanning meltdowns and general memory stress.
> 
> I'd expect trouble here because of the taking of a LRU lock per page.

PG_reclaim is there to prevent that problem (amongst other things).

If the proportion of written-back pages due to the page scanner is large,
things already suck.  The VM tries to minimise that IO and to maximise the
inode-based writeback.

> For 
> large amounts of concurrent I/O this could be an issue.
> 
> > > One additional issue that is raised by the writeback pages remaining on 
> > > the LRU lists is that we can get into the same livelock situation as with 
> > > mlocked pages if we keep on skipping over writeback pages.
> > 
> > That's why we rotate the reclaimable pages back to the head-of-queue.
> 
> I think the reclaim writeout is one minor contributor here.

To what?

> If there are 
> large amounts of writeback pages from f.e. streaming general I/O then we 
> may run still into bad situations because we need to scan over them.

If the inactive list is small relative to the number of under-writeback
pages in the zone then there could be problems there.  But we just throttle
and wait for some pages to come clean, which seems to work OK.


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: Drop PageReclaim()

[Rik van Riel]

Andrew Morton wrote:

> Well.  IO.  People still seem to thing that vmscan.c is about page
> replacement.  It ain't.  Most of the problems in there and most of the work
> which has gone into it are IO-related.

It's about both.  VM researchers should take note of Andrew's
comment though - page replacement algorithms need to take IO
into account before they can be implemented practically.

For example, any clock-like algorithm will need something to
prevent the VM from starting writeout on way too much memory
at once, as well as something to make it easy to find the
pages that were dirty when last seen by pageout, but just
became easily freeable...

Part of the reason I'm writing this down is so I won't forget
it, but it is also for others.  The development on vmscan.c
has usually been reactive - fix problems as we run into them -
with little understanding of the overall picture.

This is very different from eg. filesystems or networking,
where a lot of things get designed up-front, and it is a
miracle that the VM in the 2.6 kernel works as well as it
does.

I do not believe we can continue this way though.  With
very large memory systems becoming more and more common
and the speed gap between RAM and disk growing we'll have
to figure out the big picture one of these days, or at
least have a checklist of dos and don'ts that anybody
writing a VM patch can check against before submission :)

-- 
Politics is the struggle between those who want to make their country
the best in the world, and those who believe it already is.  Each group
calls the other unpatriotic.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>