lkml.org 
[lkml]   [2001]   [Aug]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 2.4.8/2.4.9 VM problems
On Tue, 21 Aug 2001, Daniel Phillips wrote:

> I have to admit, the 100 FTP clients case wasn't on the top of my
> mind. Even so, think about what is really happening. Nothing is
> getting activated and nothing is competing with these allocations so

> Assuming that some of the files are more popular than others, these
> file pages will be touched more than once and will go onto the active
> ring, also exactly what you want.

... and so you contradict yourself in consecutive
paragraphs...

> As they get old they get fed into the inactive queue at a rate that's
> tunable. I don't see what the problem is.

You just pointed it out. The old pages get fed into the
inactive queue at a rate which isn't influenced by how
much pressure the new pages put on the VM, but only by
some "tunable" rate.

> There are a couple of simple improvements that can be made. We could mark
> all new pages referenced, age=1 (to distinguish from aged-to-zero pages). We
> would not do unlazy activation but just allow age to increment with each
> touch. Then, in addition to the Referenced test, we would test the age
> against a tunable threshold to decide which pages to rescue. You can see
> that this would take care of your 100 streaming clients case nicely, while
> not negatively affecting the cases that are already working well.

Nice way to fuck up the 100 streaming client case even more, you mean.

> A second simple improvement is to have separate activation and deactivation
> queues. This allows you to tune the rate at which pages are pulled from the
> activation queue (these would be the streaming IO pages) against pages culled
> from the active list. I can't think of any downside at all for doing this,
> except that it's not something I'd consider appropriate for the 2.4 series.

This is called "better page aging".

> > [...] you haven't yet made any
> > proposal on how to make the rest of the VM interact nicely
> > with the use-once idea, preventing things like the thrashing
> > of the readahead window, etc...
>
> This is hypothetical thrashing so far, have you see it in the wild?

Yes.

Rik
--
IA64: a worthy successor to i860.

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

Send all your spam to aardvark@nl.linux.org (spam digging piggy)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 12:57    [W:0.066 / U:2.028 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site