Re: Time for a pre-patch-2.0.31-3?

Mark Hemment (markhe@sco.COM)
Thu, 3 Jul 1997 13:06:05 +0100 (BST)


I'd suspect the change at the end of refill_freelist(), and
try_to_free_page() to be causing some problems - mainly with throwing away
readahead pages.

The priority GFP_BUFFER now cause page reaping, normally from the
page-cache in mm/filemap.c/shrink_mmap(). As unmapped pages are not
aged (and, no, please do not try to age them!), they are easy targets.
Unfortunately, pages which have been read-ahead are unmapped...

Previously, refill_freelist() wouldn't grow buffers if there was not
enough free-memory available, and if the GFP_ATOMIC failed 'bdflush' would
be run.

Trying running 'top' to find out the highwater of buffers with and without
the patch.

This is just I guess. I haven't been able to try the patch out.

Regards,

markhe

-----------------------------------------------------
Mark Hemment UNIX/C Software Engineer (contractor)
"Success has many fathers. Failure is a b**tard"
-----------------------------------------------------

On Thu, 3 Jul 1997, Richard Waltham wrote:
> With 2.0.29, and 2.0.30 with Pavel Krauz patch, Bonnie gives something like
>
> -------Sequential Output-------- ---Sequential Input-- --Random--
> -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
> Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU
> 100 2259 77.0 4873 28.5 1768 20.5 2119 76.9 4114 20.4 118.8 5.3
>
> And with your latest patch with pre-patch 2.0.31-2
>
> -------Sequential Output-------- ---Sequential Input-- --Random--
> -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
> Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU
> 100 2262 76.8 4841 30.6 1362 15.5 1445 52.7 1568 7.6 120.1 5.3
>
> Note the drastic fall in read performance. :( These results are consistent.