Re: unexpected paging during large file reads in 2.1.127

Re: unexpected paging during large file reads in 2.1.127

[Zlatko Calusic]

Rik van Riel <H.H.vanRiel@phys.uu.nl> writes:

> On 12 Nov 1998, Zlatko Calusic wrote:
> > "David J. Fred" <djf@ic.net> writes:
> > 
> > > Summary: When doing large file reads from disk the system pages
> > >          unexpectedly causing moderate to severe degradation in I/O
> > >          and overall system performance even though there is plenty of
> > >          memory.
> > 
> > Page cache is definitely too aggressive on recent kernels. I
> > developed a small patch that avoids excessive swapouts. It helps
> > kswapd to have less trouble reusing pages from page cache. 
> 
> Agreed, we should do something about that.
> 
> > +			age_page(page);
> > +			age_page(page);
> >  			age_page(page);
> 
> Do I hear "priority paging"? :))
> 
> >        count_max = (limit<<2) >> (priority>>1);
> >        count_min = (limit<<2) >> (priority);
> 
> Maybe increasing these has the same effect but with
> the advantage of keeping page aging intact.
> 

Maybe, but then again maybe not.

I have a feeling that change like that could easily make kswapd a CPU
pig.

We are aging pages, so that they don't get reaped easily, and then
trying to compensate that with heavier scanning. Doesn't sound like a
good idea. Sizif's job.

But still, looks interesting, so I'm just going to compile one test
kernel with bigger count limits, for the fun's sake... :)

[Cc: Linux-MM]

Regards,
-- 
Posted by Zlatko Calusic           E-mail: <Zlatko.Calusic@CARNet.hr>
---------------------------------------------------------------------
	  A chicken is an egg's way of producing more eggs.
--
This is a majordomo managed list.  To unsubscribe, send a message with
the body 'unsubscribe linux-mm me@address' to: majordomo@kvack.org

Re: unexpected paging during large file reads in 2.1.127

[Zlatko Calusic]

OK, benchmarking done (never faster :))

Methodology: compile kernel, reboot, fire up X, XEmacs, Netscape, few
xterms to (almost) fill memory, copy 1.5GB of files to /dev/null.

I have 64MB of memory, and interesting thing, in both cases I tried,
system decided to swap out cca 16MB, which is fine. Without patching,
kernel would start thrashing very early, during file copy, which
considerably slows down whole operation (and make machine painfully
sloooow).


*** Case 1)

shrink_mmap():
        count_max = (limit<<4) >> (priority>>1);
        count_min = (limit<<4) >> (priority);

Result after copying is finished:
    3 root       7   7     0    0     0 SWN     0  0.0  0.0   0:13 kswapd
                                                              ^^^^


*** Case 2)

shrink_one_page():
        age_page(page);
        age_page(page);
        age_page(page);

Result after copying is finished:
    3 root       7   7     0    0     0 SWN     0  0.0  0.0   0:07 kswapd
                                                              ^^^^


Tested on pre-2.1.128-1.

Q.E.D. :)
-- 
Posted by Zlatko Calusic           E-mail: <Zlatko.Calusic@CARNet.hr>
---------------------------------------------------------------------
		    Bus error (Passengers dumped)
--
This is a majordomo managed list.  To unsubscribe, send a message with
the body 'unsubscribe linux-mm me@address' to: majordomo@kvack.org

Re: unexpected paging during large file reads in 2.1.127

[Stephen C. Tweedie]

Hi,

On 12 Nov 1998 23:45:42 +0100, Zlatko Calusic <Zlatko.Calusic@CARNet.hr>
said:

>> Agreed, we should do something about that.
>> 
>> > +			age_page(page);
>> > +			age_page(page);
>> >  			age_page(page);

The real cure is to disable page aging in the page cache completely.
Now that we have disabled it for swap, it makes absolutely no sense at
all to keep it in the page cache.

--Stephen
--
This is a majordomo managed list.  To unsubscribe, send a message with
the body 'unsubscribe linux-mm me@address' to: majordomo@kvack.org

Re: unexpected paging during large file reads in 2.1.127

[Rik van Riel]

On Mon, 16 Nov 1998, Stephen C. Tweedie wrote:
> On 12 Nov 1998 23:45:42 +0100, Zlatko Calusic <Zlatko.Calusic@CARNet.hr>
> said:
> 
> >> Agreed, we should do something about that.
> >> 
> >> > +			age_page(page);
> >> > +			age_page(page);
> >> >  			age_page(page);
> 
> The real cure is to disable page aging in the page cache completely.
> Now that we have disabled it for swap, it makes absolutely no sense at
> all to keep it in the page cache.

This is not entirely true. There is a major difference
between pages in the page cache and pages that can go
into swap. The latter kind will always be mapped inside
the address space of a program (where it gets proper
aging and stuff), while file data could be used by
doing a read() where the data never gets mapped into
the processes address space.

Now we can get severe problems with readahead when we
are evicting just read-in data because it isn't mapped,
resulting in us having to read it again and doing double
I/O with a badly performing program.

The only reason why it's better than the alternative is
because we don't do swap readahead yet...

cheers,

Rik -- slowly getting used to dvorak kbd layout...
+-------------------------------------------------------------------+
| Linux memory management tour guide.        H.H.vanRiel@phys.uu.nl |
| Scouting Vries cubscout leader.      http://www.phys.uu.nl/~riel/ |
+-------------------------------------------------------------------+

--
This is a majordomo managed list.  To unsubscribe, send a message with
the body 'unsubscribe linux-mm me@address' to: majordomo@kvack.org

Re: unexpected paging during large file reads in 2.1.127

[Zlatko Calusic]

"Stephen C. Tweedie" <sct@redhat.com> writes:

> Hi,
> 
> On 12 Nov 1998 23:45:42 +0100, Zlatko Calusic <Zlatko.Calusic@CARNet.hr>
> said:
> 
> >> Agreed, we should do something about that.
> >> 
> >> > +			age_page(page);
> >> > +			age_page(page);
> >> >  			age_page(page);
> 
> The real cure is to disable page aging in the page cache completely.
> Now that we have disabled it for swap, it makes absolutely no sense at
> all to keep it in the page cache.
> 

Probably. That leaves the fastest kernel of all tested (you can feel
it, you can measure it).

But, still, I like that my system pages out, but slowly, over
time. Solaris behaves like that, and it is OK if it's not too
aggressive. Not that Solaris makes good etalon at anything, but... :)

You are still right, though, no aging at all will make many things go
faster.

Regards,
-- 
Posted by Zlatko Calusic           E-mail: <Zlatko.Calusic@CARNet.hr>
---------------------------------------------------------------------
	     Do not put statements in the negative form.
--
This is a majordomo managed list.  To unsubscribe, send a message with
the body 'unsubscribe linux-mm me@address' to: majordomo@kvack.org

Re: unexpected paging during large file reads in 2.1.127

[Stephen C. Tweedie]

Hi,

On Mon, 16 Nov 1998 21:48:35 +0100 (CET), Rik van Riel
<H.H.vanRiel@phys.uu.nl> said:

> On Mon, 16 Nov 1998, Stephen C. Tweedie wrote:
>> The real cure is to disable page aging in the page cache completely.
>> Now that we have disabled it for swap, it makes absolutely no sense at
>> all to keep it in the page cache.

> This is not entirely true. There is a major difference
> between pages in the page cache and pages that can go
> into swap. The latter kind will always be mapped inside
> the address space of a program (where it gets proper
> aging and stuff)

No it doesn't, that's what I'm saying.  Linus removed swap page aging in
the recent kernels.  That throws the balance between swap and cache
completely out of the window: removing the page cache aging is necessary
to restore balance.  There are many many reports of massive cache growth
on the latest kernels as a result of this.

> Now we can get severe problems with readahead when we
> are evicting just read-in data because it isn't mapped,

No, we don't.  We don't evict just-read-in data, because we mark such
pages as PG_Referenced.  It takes two complete shrink_mmap() passes
before we can evict such pages.

> resulting in us having to read it again and doing double
> I/O with a badly performing program.

The reason why this used to happen was because the readahead failed to
mark the new page as PG_Referenced.  I've been saying for _months_ that
the right fix was to mark them referenced rather than to do page aging
(and all of my benchmarks, without exception, back this up).  

--Stephen
--
This is a majordomo managed list.  To unsubscribe, send a message with
the body 'unsubscribe linux-mm me@address' to: majordomo@kvack.org

Re: unexpected paging during large file reads in 2.1.127

[Zlatko Calusic]

"Stephen C. Tweedie" <sct@redhat.com> writes:

> Hi,
> 
> On Mon, 16 Nov 1998 21:48:35 +0100 (CET), Rik van Riel
> <H.H.vanRiel@phys.uu.nl> said:
> 
> > On Mon, 16 Nov 1998, Stephen C. Tweedie wrote:
> >> The real cure is to disable page aging in the page cache completely.
> >> Now that we have disabled it for swap, it makes absolutely no sense at
> >> all to keep it in the page cache.
> 

[snip]

> No, we don't.  We don't evict just-read-in data, because we mark such
> pages as PG_Referenced.  It takes two complete shrink_mmap() passes
> before we can evict such pages.

I didn't find this in the source (in fact, add_to_page_cache clears
PG_referenced bit, if I understood source correctly). But, see below.

> 
> > resulting in us having to read it again and doing double
> > I/O with a badly performing program.
> 
> The reason why this used to happen was because the readahead failed to
> mark the new page as PG_Referenced.  I've been saying for _months_ that
> the right fix was to mark them referenced rather than to do page aging
> (and all of my benchmarks, without exception, back this up).  
> 

I must agree entirely, because with small patch you can find below,
performance is very very good. Thanks to marking readahead pages as
referenced, I've been able to see exact behaviour that I wanted for a
long time. And that is, if the page cache is too small, and we start
doing lots of I/O, then it should expand slightly. Otherwise it should
be quiet, I mean, we don't want any swapouts, since that would degrade
our I/O performance.

Everybody, try the attached patch (that Stephen was suggesting long
ago, IIRC) and see for yourself. My machine is flying now. :)

Index: 128.2/mm/filemap.c
--- 128.2/mm/filemap.c Mon, 16 Nov 1998 23:45:38 +0100 zcalusic (linux-2.1/y/b/29_filemap.c 1.2.4.1.1.1 644)
+++ 128.3(w)/mm/filemap.c Tue, 17 Nov 1998 01:41:53 +0100 zcalusic (linux-2.1/y/b/29_filemap.c 1.2.4.1.1.2 644)
@@ -172,20 +172,14 @@
 				delete_from_swap_cache(page);
 				return 1;
 			}
-			if (test_and_clear_bit(PG_referenced, &page->flags)) {
-				touch_page(page);
-				break;
-			}
-			age_page(page);
-			if (page->age)
+			if (test_and_clear_bit(PG_referenced, &page->flags))
 				break;
 			if (pgcache_under_min())
 				break;
 			remove_inode_page(page);
 			return 1;
 		}
-		/* It's not a cache page, so we don't do aging.
-		 * If it has been referenced recently, don't free it */
+		/* if page has been referenced recently, don't free it */
 		if (test_and_clear_bit(PG_referenced, &page->flags))
 			break;
 
@@ -212,8 +206,8 @@
 	struct page * page;
 	int count_max, count_min;
 
-	count_max = (limit<<2) >> (priority>>1);
-	count_min = (limit<<2) >> (priority);
+	count_max = (limit<<1) >> (priority>>1);
+	count_min = (limit<<1) >> (priority);
 
 	page = mem_map + clock;
 	do {
@@ -328,6 +322,7 @@
 			 */
 			page = mem_map + MAP_NR(page_cache);
 			add_to_page_cache(page, inode, offset, hash);
+			set_bit(PG_referenced, &page->flags);
 			inode->i_op->readpage(file, page);
 			page_cache = 0;
 		}

Regards,
-- 
Posted by Zlatko Calusic           E-mail: <Zlatko.Calusic@CARNet.hr>
---------------------------------------------------------------------
		 43% of all statistics are worthless.
--
This is a majordomo managed list.  To unsubscribe, send a message with
the body 'unsubscribe linux-mm me@address' to: majordomo@kvack.org

Re: unexpected paging during large file reads in 2.1.127

[Rik van Riel]

On Mon, 16 Nov 1998, Stephen C. Tweedie wrote:
> On Mon, 16 Nov 1998 21:48:35 +0100 (CET), Rik van Riel
> <H.H.vanRiel@phys.uu.nl> said:
> > On Mon, 16 Nov 1998, Stephen C. Tweedie wrote:
> >> The real cure is to disable page aging in the page cache completely.
> >> Now that we have disabled it for swap, it makes absolutely no sense at
> >> all to keep it in the page cache.
> 
> > This is not entirely true. There is a major difference
> > between pages in the page cache and pages that can go
> > into swap. The latter kind will always be mapped inside
> > the address space of a program (where it gets proper
> > aging and stuff)
> 
> No it doesn't, that's what I'm saying.  Linus removed swap page aging in
> the recent kernels.  That throws the balance between swap and cache
> completely out of the window: removing the page cache aging is necessary
> to restore balance.  There are many many reports of massive cache growth
> on the latest kernels as a result of this.

I meant the page aging that occurs in vmscan.c, where we
decide on which page to unmap from a program's address
space. There we do aging while we don't age pages from
files that are read().

> > Now we can get severe problems with readahead when we
> > are evicting just read-in data because it isn't mapped,
> 
> No, we don't.  We don't evict just-read-in data, because we mark such
> pages as PG_Referenced.  It takes two complete shrink_mmap() passes
> before we can evict such pages.

OK, I can (and have for quite a while) agree with this.
Kernels with this feature and enough memory will run great,
maybe small machines (<16M) will have a bit of trouble
keeping up readahead performance (since kswapd will have
made it's round a bit fast) but those machines will have
sucky performance anyway :)

Rik -- slowly getting used to dvorak kbd layout...
+-------------------------------------------------------------------+
| Linux memory management tour guide.        H.H.vanRiel@phys.uu.nl |
| Scouting Vries cubscout leader.      http://www.phys.uu.nl/~riel/ |
+-------------------------------------------------------------------+

--
This is a majordomo managed list.  To unsubscribe, send a message with
the body 'unsubscribe linux-mm me@address' to: majordomo@kvack.org

Re: unexpected paging during large file reads in 2.1.127

[Stephen C. Tweedie]

Hi,

On 17 Nov 1998 02:21:14 +0100, Zlatko Calusic <Zlatko.Calusic@CARNet.hr>
said:

> "Stephen C. Tweedie" <sct@redhat.com> writes:

>> No, we don't.  We don't evict just-read-in data, because we mark such
>> pages as PG_Referenced.  It takes two complete shrink_mmap() passes
>> before we can evict such pages.

> I didn't find this in the source (in fact, add_to_page_cache clears
> PG_referenced bit, if I understood source correctly). But, see below.

You didn't understand the source correctly. :)  There is an extra
bracket you missed:

	page->flags = (page->flags & ~((1 << PG_uptodate) | (1 << PG_error))) | (1 << PG_referenced);

We clear PG_uptodate and PG_error, but we _set_ PG_referenced.

> I must agree entirely, because with small patch you can find below,
> performance is very very good. Thanks to marking readahead pages as
> referenced, I've been able to see exact behaviour that I wanted for a
> long time. 

Excellent.  

--Stephen
--
This is a majordomo managed list.  To unsubscribe, send a message with
the body 'unsubscribe linux-mm me@address' to: majordomo@kvack.org

Re: unexpected paging during large file reads in 2.1.127

[Stephen C. Tweedie]

Hi,

On Tue, 17 Nov 1998 07:42:12 +0100 (CET), Rik van Riel
<H.H.vanRiel@phys.uu.nl> said:

> I meant the page aging that occurs in vmscan.c, where we
> decide on which page to unmap from a program's address
> space. 

For the last time, NO IT DOES NOT.  Read the source.  Linus removed it.
We do not use page->age AT ALL in vmscan.c in current 2.1 kernels.

> There we do aging while we don't age pages from files that are read().

For the last time, YES WE DO.  shrink_mmap() for the page cache in
mm/filemap.c still uses page aging in current 2.1 kernels.  Read() uses
the page cache.

This is a problem.

> OK, I can (and have for quite a while) agree with this.
> Kernels with this feature and enough memory will run great,
> maybe small machines (<16M) will have a bit of trouble
> keeping up readahead performance (since kswapd will have
> made it's round a bit fast) but those machines will have
> sucky performance anyway :)

This change improves low memory performance very measurably in all tests
I have tried so far.

--Stephen.
--
This is a majordomo managed list.  To unsubscribe, send a message with
the body 'unsubscribe linux-mm me@address' to: majordomo@kvack.org

Re: unexpected paging during large file reads in 2.1.127

[Rik van Riel]

On Tue, 17 Nov 1998, Stephen C. Tweedie wrote:
> On Tue, 17 Nov 1998 07:42:12 +0100 (CET), Rik van Riel
> <H.H.vanRiel@phys.uu.nl> said:
> 
> > I meant the page aging that occurs in vmscan.c, where we
> > decide on which page to unmap from a program's address
> > space. 
> 
> For the last time, NO IT DOES NOT.  Read the source.  Linus removed it.
> We do not use page->age AT ALL in vmscan.c in current 2.1 kernels.

I just learned that answering questions from memory is
not a good idea when reality changes under your nose :)

I'll try to remember this, really...

> This change improves low memory performance very measurably in all
> tests I have tried so far. 

OK, I agree with these changes and have seen a bit of
improvement on my own (72M) system too.

cheers,

Rik -- slowly getting used to dvorak kbd layout...
+-------------------------------------------------------------------+
| Linux memory management tour guide.        H.H.vanRiel@phys.uu.nl |
| Scouting Vries cubscout leader.      http://www.phys.uu.nl/~riel/ |
+-------------------------------------------------------------------+

--
This is a majordomo managed list.  To unsubscribe, send a message with
the body 'unsubscribe linux-mm me@address' to: majordomo@kvack.org

Re: unexpected paging during large file reads in 2.1.127

[Zlatko Calusic]

"Stephen C. Tweedie" <sct@redhat.com> writes:

> Hi,
> 
> On 17 Nov 1998 02:21:14 +0100, Zlatko Calusic <Zlatko.Calusic@CARNet.hr>
> said:
> 
> > "Stephen C. Tweedie" <sct@redhat.com> writes:
> 
> >> No, we don't.  We don't evict just-read-in data, because we mark such
> >> pages as PG_Referenced.  It takes two complete shrink_mmap() passes
> >> before we can evict such pages.
> 
> > I didn't find this in the source (in fact, add_to_page_cache clears
> > PG_referenced bit, if I understood source correctly). But, see below.
> 
> You didn't understand the source correctly. :)  There is an extra
> bracket you missed:
> 
> 	page->flags = (page->flags & ~((1 << PG_uptodate) | (1 << PG_error))) | (1 << PG_referenced);
> 
> We clear PG_uptodate and PG_error, but we _set_ PG_referenced.

Oops. My apologies. You're right, of course.

That makes one line in my patch superfluous.

Although I have some experience in LISP, it looks like I still have
trouble counting parentheses (LISP = Lost In Stupid Parentheses). :)

Still, a small comment above that line would be extremely helpful.

> 
> > I must agree entirely, because with small patch you can find below,
> > performance is very very good. Thanks to marking readahead pages as
> > referenced, I've been able to see exact behaviour that I wanted for a
> > long time. 
> 
> Excellent.  
> 

Pleasure is all mine. :)

I mean, bits from the patch are coming exclusively from you.

I'm really looking forward to their integration in the mainstream,
because performance improvement is so dramatic that I expect lots of
comments on the linux-kernel list telling that "latest 2.1.xxx is so
much faster".

Thanks for your good work!
-- 
Posted by Zlatko Calusic           E-mail: <Zlatko.Calusic@CARNet.hr>
---------------------------------------------------------------------
	"Luke... Luke... Use the MOUSE, Luke" - Obi Wan Gates
--
This is a majordomo managed list.  To unsubscribe, send a message with
the body 'unsubscribe linux-mm me@address' to: majordomo@kvack.org