lkml.org 
[lkml]   [2006]   [Mar]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 00/34] mm: Page Replacement Policy Framework
Hi Nick,

On Thu, Mar 23, 2006 at 01:21:08PM +1100, Nick Piggin wrote:
> Andrew Morton wrote:
> >Peter Zijlstra <a.p.zijlstra@chello.nl> 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,
> >>even
> >>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@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: 2006-03-23 19:16    [W:0.127 / U:0.052 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site