Re: [PATCH 00/34] mm: Page Replacement Policy Framework
From: Marcelo Tosatti
Date: Thu Mar 23 2006 - 13:10:58 EST
On Thu, Mar 23, 2006 at 01:21:08PM +1100, Nick Piggin wrote:
> Andrew Morton wrote:
> >Peter Zijlstra <a.p.zijlstra@xxxxxxxxx> wrote:
> >>This patch-set introduces a page replacement policy framework and 4 new
> >>experimental policies.
> >Holy cow.
> >>The page replacement algorithm determines which pages to swap out.
> >>The current algorithm has some problems that are increasingly noticable,
> >>on desktop workloads.
> >Rather than replacing the whole lot four times I'd really prefer to see
> >precise descriptions of these problems, see if we can improve the situation
> >incrementally rather than wholesale slash-n-burn...
> The other thing is that a lot of the "policy" stuff you've abstracted
> out is actually low-level "mechanism" stuff that has implications beyond
> page reclaim. Taking a refcount on lru pages, for example.
On "cache pages" you mean :)
Yes, some low-level mechanisms have also been abstracted away... I think
a nice way to avoid explicit knowledge of page reference acquision at
the moment of candidate selection hasnt been found.
Do you have any suggestions?
> you should be submitting them (eg. patch 25, or patch 1) rather than
> sitting on them and sending them in a huge patchset where they don't
> really belong.
I guess Peter and myself expected folks to criticise and help shape the
API to something acceptable.
BTW, patches 1 and 25 are not crucial improvements for mainline (there's
not much point in having them in mainline), and I don't see any others?
> Some of the API names aren't very nice either. It's great that you want
> to keep the namespace consistent, but it shouldn't be at the expense of
> more descriptive names, and having the page_replace_ prefix itself makes
> many functions read like crap. I'd suggest something like a pgrep_
> prefix and try to make the rest of the name make sense.
"pgrep_" looks more pleasant to me.
> Aside from all that, I'm with Andrew in that problems need to be
> identified first and foremost.
See my previous message.
> But also I don't like the chances of this
> whole framework flying at all -- Linus vetoed a similar framework for
> sched.c that was actually a reasonable API, with little or no
> consequences outside sched.c. With good reason.
Aren't we talking about very different things here? IMHO there is a lot
of point in allowing pluggable page replacement instead of trying to
make one policy fit all needs (which is obviously impossible).
> Nice work, though :)
Indeed - Peter has done a very nice job.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/