On Wed, 30 May 2001, Jonathan Morton wrote:
> >The page aging logic does seems fragile as heck. You never know how
> >many folks are aging pages or at what rate. If aging happens too fast,
> >it defeats the garbage identification logic and you rape your cache. If
> >aging happens too slowly...... sigh.
>
> Then it sounds like the current algorithm is totally broken and needs
> replacement. If it's impossible to make a system stable by choosing the
> right numbers, the system needs changing, not the numbers. I think that's
> pretty much what we're being taught in Control Engineering. :)
I wouldn't go so far as to say totally broken (mostly because I've tried
like _hell_ to find a better way, and [despite minor successes] I've not
been able to come up with something which covers all cases that even _I_
[hw tech] can think of well). Hard numbers are just plain bad, see below.
I _will_ say that it is entirely too easy to break for comfort ;-)
> Not having studied the code too closely, it sounds as though there are half
> a dozen different "clocks" running for different types of memory, and each
> one runs at a different speed and is updated at a different time.
> Meanwhile, the paging-out is done on the assumption that all the clocks are
> (at least roughly) in sync. Makes sense, right? (not!)
No, I don't think that's the case at all. The individual zone balancing
logic (or individual page [content] type logic) hasn't been inplimented
yet (content type handling I don't think we want), but doesn't look like
it'll be any trouble to do with the structures in place. That's just a
fleshing out thing. The variations in aging rate is the most difficult
problem I can see. IMHO, it needs to be either decoupled and done by an
impartial bystander (tried that, ran into info flow troubles because of
scheduling) or integrated tightly into the allocator proper (tried that..
interesting results but has problems of it's own wrt the massive changes
in general strategy needed to make it work.. approaches rewrite)
> I think it's worthwhile to think of the page/buffer caches as having a
> working set of their own - if they are being heavily used, they should get
> more memory than if they are only lightly used. The important point to get
> right is to ensure that the "clocks" used for each memory area remain in
> sync - they don't have to measure real time, just be consistent and fine
> granularity.
IMHO, the only thing of interest you can do with clocks is set your state
sample rate. If state is changing rapidly, you must sample rapidly. As
far as corrections go, you can only insert a corrective vector into the
mix and then see if the sum induced the desired change in direction. The
correct magnitude of this vector is not even possible to know.. that's
what makes it so darn hard [defining numerical goals is utterly bogus].
> I'm working on some relatively small changes to vmscan.c which should help
> improve the behaviour without upsetting the balance too much. Watch this
> space...
With much interest :)
-Mike
-
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/
This archive was generated by hypermail 2b29 : Thu May 31 2001 - 21:00:46 EST