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:5.092 / U:0.156 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site