Re: (lkml)Re: spindown [was Re: 2.4.6-pre2, pre3 VM Behavior]

[Mike Galbraith <mikeg@wen-online.de>]

On Sun, 17 Jun 2001 thunder7@xs4all.nl wrote:

> On Sun, Jun 17, 2001 at 12:05:10PM +0200, Mike Galbraith wrote:
> >
> > It _juuust_ so happens that I was tinkering... what do you think of
> > something like the below?  (and boy do I ever wonder what a certain
> > box doing slrn stuff thinks of it.. hint hint;)
> >
> I'm sorry to say this box doesn't really think any different of it.

Well darn.  But..

> Everything that's in the cache before running slrn on a big group seems
> to stay there the whole time, making my active slrn-process use swap.

It should not be the same data if page aging is working at all.  Better
stated, if it _is_ the same data and page aging is working, it's needed
data, so the movement of momentarily unused rss to disk might have been
the right thing to do.. it just has to buy you the use of the pages moved
for long enough to offset the (large) cost of dropping those pages.

I saw it adding rss to the aging pool, but not terribly much IO.  The
fact that it is using page replacement is only interesting in regard to
total system efficiency.

> I applied the patch to 2.4.5-ac15, and this was the result:

<saves vmstat>

Thanks for running it.  Can you (afford to) send me procinfo or such
(what I would like to see is job efficiency) information?  Full logs
are fine, as long as they're not truely huge :)  Anything under a meg
is gratefully accepted (privately 'course).

I think (am pretty darn sure) the aging fairness change is what is
affecting you, but it's not possible to see whether this change is
affecting you in a negative or positive way without timing data.

	-Mike

misc:

wrt this ~patch, it only allows you to move the rolldown to sync disk
behavior some.. moving write delay back some (knob) is _supposed_ to
get that IO load (at least) a modest throughput increase.  The flushto
thing was basically directed toward laptop use, but ~seems to exhibit
better IO clustering/bandwidth sharing as well.  (less old/new request
merging?.. distance?)