Subject: Re: ioflush is taking excessive cycles on a big-memory machine
To: NetBSD Kernel Technical Discussion List <tech-kern@NetBSD.org>
From: Greg A. Woods <firstname.lastname@example.org>
Date: 04/05/2005 01:17:33
[ On Monday, April 4, 2005 at 21:23:01 (-0600), Rick Kelly wrote: ]
> Subject: Re: ioflush is taking excessive cycles on a big-memory machine
> Jonathan Stone said:
> > I've lost track, sorry. Is this 1.6 again, or something newer?
Yes, sorry, I should have reiterated that it is indeed an alpha running
a 1.6.x kernel.
> A quick perusal of all my machines that are 2.0 or greater shows that they
> all have ioflush as the top system process. This seems to be not true of
> 1.6.x machines.
On all my 1.6.x machines the ioflush thread has some time accumulated,
but not a huge amount and it isn't constantly soaking up highly
noticable numbers of CPU cycles on any of them.
Jason Thorpe says:
> Known "issue".
Ah, thought so, but I coudn't find any obvious claims with some quick
Does anyone have any thoughts on how to deal with this issue?
A bitmap for the dirty page flags maybe?
Don't get me wrong -- I really do like to be able to grow the filecache
as big as possible, but if it takes ever increasing amounts of CPU just
to wander through a large filecache page set then I can only afford to
have the filecache stay big for a relatively short period of time. (and
I'm sure other folks might even want to have some knob to allow them to
truly cap the maximum number of pages that can ever be used)
In lieu of a better dirty-page search algorithm I'd even settle for a
"manual" way to free some of the unused pages -- and hopefully it could
be some least intrusive mechanism, i.e. a way that does not require
firing up a big process to steal, err, reclaim, them back to some other
use, e.g. anon pages. E.g. a simple system call like sync(2), but one
which accepts some parameter suggesting how many to free (do filecache
pages have something like a last-used timestamp?).
Jason also says:
> (Hey, at least the time spent flushing pages is properly accounted for...)
Is there a better way to find the current number of filecache pages
allocated using some tool other than "systat buf"? I've peered through
the "vmstat -m" output but can't seem to find a corresponding number to
what systat shows.
Greg A. Woods
H:+1 416 218-0098 W:+1 416 489-5852 x122 VE3TCP RoboHack <email@example.com>
Planix, Inc. <firstname.lastname@example.org> Secrets of the Weird <email@example.com>