lkml.org 
[lkml]   [2002]   [Mar]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: 2.4.19pre1aa1
    On Tue, 5 Mar 2002, Andrea Arcangeli wrote:
    > On Mon, Mar 04, 2002 at 06:36:47PM -0300, Rik van Riel wrote:
    > > On Mon, 4 Mar 2002, Andrea Arcangeli wrote:
    > >
    > > > > 2) We can do local per-node scanning - no need to bounce
    > > > > information to and fro across the interconnect just to see what's
    > > > > worth swapping out.
    > > >
    > > > the lru lists are global at the moment, so for the normal swapout
    > > > activitiy rmap won't allow you to do what you mention above
    > >
    > > Actually, the lru lists are per zone and have been for a while.
    >
    > They're not in my tree

    Yeah, but you shouldn't judge rmap by what's in your tree ;))

    Balancing is quite simple, too.

    > > The thing which was lacking up to now is a pagecache_lru_lock
    > > per zone, because this clashes with truncate(). Arjan came up
    > > with a creative solution to fix this problem and I'll integrate
    > > it into -rmap soon...
    >
    > making it a per-lru spinlock is natural scalability optimization, but
    > anyways pagemap_lru_lock isn't a very critical spinlock.

    That's what I used to think, too. The folks at IBM showed
    me I was wrong and the pagemap_lru_lock is critical.


    > > I'd appreciate it if you could look at the implementation and
    > > look for areas to optimise. However, note that I don't believe
    >
    > I didn't had time to look too much into that yet (I had only a short
    > review so far), but I will certainly do that in some more time, looking
    > at it with a 2.5 long term prospective. I didn't liked too much that you
    > resurrected some of the old code that I don't think pays off. I would
    > preferred if you had rmap on top of my vm patch without reintroducing
    > the older logics. I still don't see the need of inactive_dirty and the
    > fact you dropped classzone and put the unreliable "plenty stuff" that
    > reintroduces design bugs that will lead kswapd go crazy again. But ok, I
    > don't worry too much about that, the rmap bits that maintains the
    > additional information are orthogonal with the other changes and that's
    > the interesting part of the patch after all.

    OK, lets try to put classzone on top of a Hammer "NUMA" system.

    You'll have one CPU starting to allocate from zone A, falling
    back to zone B and then further down.

    Another CPU starts allocating at zone B, falling back to A
    and then further down.

    How would you express this in classzone ? I've looked at it
    for quite a while and haven't found a clean way to get this
    situation right with classzone, which is why I have removed
    it.

    As for kswapd going crazy, that is nicely fixed by having
    per zone lru lists... ;)

    regards,

    Rik
    --
    "Linux holds advantages over the single-vendor commercial OS"
    -- Microsoft's "Competing with Linux" document

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

    -
    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 13:24    [W:0.046 / U:0.044 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site