write drop behind effect on active scanning

write drop behind effect on active scanning

[Marcelo Tosatti]

Hi, 

I just noticed a "bad" effect of write drop behind yesterday during some
tests.

The problem is that we deactivate written pages, thus making the inactive
list become pretty big (full of unfreeable pages) under write intensive IO
workloads.

So what happens is that we don't do _any_ aging on the active list, and in
the meantime the inactive list (which should have "easily" freeable
pages) is full of locked pages. 

I'm going to fix this one by replacing "deactivate_page(page)" to
"ClearPageReferenced(page)" in generic_file_write(). This way the written
pages are aged faster but we avoid the bad effect just described.

Any comments on the fix ?  

--
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.eu.org/Linux-MM/

Re: write drop behind effect on active scanning

[Marcelo Tosatti]

On Wed, 23 May 2001, Daniel Phillips wrote:

> On Wednesday 23 May 2001 09:33, Marcelo Tosatti wrote:
> > Hi,
> >
> > I just noticed a "bad" effect of write drop behind yesterday during
> > some tests.
> >
> > The problem is that we deactivate written pages, thus making the
> > inactive list become pretty big (full of unfreeable pages) under
> > write intensive IO workloads.
> >
> > So what happens is that we don't do _any_ aging on the active list,
> > and in the meantime the inactive list (which should have "easily"
> > freeable pages) is full of locked pages.
> >
> > I'm going to fix this one by replacing "deactivate_page(page)" to
> > "ClearPageReferenced(page)" in generic_file_write(). This way the
> > written pages are aged faster but we avoid the bad effect just
> > described.
> >
> > Any comments on the fix ?
> 
>   page->age = 0 ?

That would make any full scan through the active list move all dropped
pages from generic_file_write() to the inactive 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.eu.org/Linux-MM/

Re: write drop behind effect on active scanning

[Daniel Phillips]

On Wednesday 23 May 2001 09:33, Marcelo Tosatti wrote:
> Hi,
>
> I just noticed a "bad" effect of write drop behind yesterday during
> some tests.
>
> The problem is that we deactivate written pages, thus making the
> inactive list become pretty big (full of unfreeable pages) under
> write intensive IO workloads.
>
> So what happens is that we don't do _any_ aging on the active list,
> and in the meantime the inactive list (which should have "easily"
> freeable pages) is full of locked pages.
>
> I'm going to fix this one by replacing "deactivate_page(page)" to
> "ClearPageReferenced(page)" in generic_file_write(). This way the
> written pages are aged faster but we avoid the bad effect just
> described.
>
> Any comments on the fix ?

  page->age = 0 ?

--
Daniel
--
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.eu.org/Linux-MM/

Re: write drop behind effect on active scanning

[Marcelo Tosatti]

On Wed, 23 May 2001, Mark Hahn wrote:

> > >   page->age = 0 ?
> > 
> > That would make any full scan through the active list move all dropped
> > pages from generic_file_write() to the inactive list.
> 
> well, that's where they're going, aren't they?
> when these pages are unlocked, they should wind up on the 
> inactive-clean list.  I think the real question is whether 
> it's worthwhile to make a separate locked list for them.
> it certainly makes no sense to have them on a/ic/id while 
> they're locked, no?

It makes sense to have a separate list for pages which are being laundered
(written out) from the inactive dirty list. 

This way we have a more "accurate" deactivation target in case the pages
on this "being written" list do not get counted as "deactivated" pages. 

This would avoid the excessive VM pressure of dirty data writeout (which
Rik just mentioned) and also avoid the "inactive dirty list full of
unfreeable pages" problem.

I don't think its a 2.4 thing, though. 

--
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.eu.org/Linux-MM/

Re: write drop behind effect on active scanning

[Mark Hahn]

> >   page->age = 0 ?
> 
> That would make any full scan through the active list move all dropped
> pages from generic_file_write() to the inactive list.

well, that's where they're going, aren't they?
when these pages are unlocked, they should wind up on the 
inactive-clean list.  I think the real question is whether 
it's worthwhile to make a separate locked list for them.
it certainly makes no sense to have them on a/ic/id while 
they're locked, no?

--
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.eu.org/Linux-MM/

Re: write drop behind effect on active scanning

[Rik van Riel]

On Wed, 23 May 2001, Marcelo Tosatti wrote:

> I just noticed a "bad" effect of write drop behind yesterday during some
> tests.
>
> The problem is that we deactivate written pages, thus making the inactive
> list become pretty big (full of unfreeable pages) under write intensive IO
> workloads.
>
> So what happens is that we don't do _any_ aging on the active list, and in
> the meantime the inactive list (which should have "easily" freeable
> pages) is full of locked pages.
>
> I'm going to fix this one by replacing "deactivate_page(page)" to
> "ClearPageReferenced(page)" in generic_file_write(). This way the written
> pages are aged faster but we avoid the bad effect just described.
>
> Any comments on the fix ?

1) I agree with it, drop-behind should make the pages we write
   very likely for eviction, but we don't want that to stop the
   eviction of other not-used pages ...

2) OTOH, if writeout of dirty pages is a problem for the system,
   I guess we will want to fix that problem somehow ;)
   (but that's another issue)

regards,

Rik
--
Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml

Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...

		http://www.surriel.com/
http://www.conectiva.com/	http://distro.conectiva.com/

--
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.eu.org/Linux-MM/