lkml.org 
[lkml]   [2011]   [Jun]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [patch 0/8] mm: memcg naturalization -rc2
    On Wed, Jun 01, 2011 at 09:05:18PM -0700, Ying Han wrote:
    > On Wed, Jun 1, 2011 at 4:52 PM, Hiroyuki Kamezawa
    > <kamezawa.hiroyuki@gmail.com> wrote:
    > > 2011/6/1 Johannes Weiner <hannes@cmpxchg.org>:
    > >> Hi,
    > >>
    > >> this is the second version of the memcg naturalization series.  The
    > >> notable changes since the first submission are:
    > >>
    > >>    o the hierarchy walk is now intermittent and will abort and
    > >>      remember the last scanned child after sc->nr_to_reclaim pages
    > >>      have been reclaimed during the walk in one zone (Rik)
    > >>
    > >>    o the global lru lists are never scanned when memcg is enabled
    > >>      after #2 'memcg-aware global reclaim', which makes this patch
    > >>      self-sufficient and complete without requiring the per-memcg lru
    > >>      lists to be exclusive (Michal)
    > >>
    > >>    o renamed sc->memcg and sc->current_memcg to sc->target_mem_cgroup
    > >>      and sc->mem_cgroup and fixed their documentation, I hope this is
    > >>      better understandable now (Rik)
    > >>
    > >>    o the reclaim statistic counters have been renamed.  there is no
    > >>      more distinction between 'pgfree' and 'pgsteal', it is now
    > >>      'pgreclaim' in both cases; 'kswapd' has been replaced by
    > >>      'background'
    > >>
    > >>    o fixed a nasty crash in the hierarchical soft limit check that
    > >>      happened during global reclaim in memcgs that are hierarchical
    > >>      but have no hierarchical parents themselves
    > >>
    > >>    o properly implemented the memcg-aware unevictable page rescue
    > >>      scanner, there were several blatant bugs in there
    > >>
    > >>    o documentation on new public interfaces
    > >>
    > >> Thanks for your input on the first version.
    > >>
    > >> I ran microbenchmarks (sparse file catting, essentially) to stress
    > >> reclaim and LRU operations.  There is no measurable overhead for
    > >> !CONFIG_MEMCG, memcg disabled during boot, memcg enabled but no
    > >> configured groups, and hard limit reclaim.
    > >>
    > >> I also ran single-threaded kernbenchs in four unlimited memcgs in
    > >> parallel, contained in a hard-limited hierarchical parent that put
    > >> constant pressure on the workload.  There is no measurable difference
    > >> in runtime, the pgpgin/pgpgout counters, and fairness among memcgs in
    > >> this test compared to an unpatched kernel.  Needs more evaluation,
    > >> especially with a higher number of memcgs.
    > >>
    > >> The soft limit changes are also proven to work in so far that it is
    > >> possible to prioritize between children in a hierarchy under pressure
    > >> and that runtime differences corresponded directly to the soft limit
    > >> settings in the previously described kernbench setup with staggered
    > >> soft limits on the groups, but this needs quantification.
    > >>
    > >> Based on v2.6.39.
    > >>
    > >
    > > Hmm, I welcome and will review this patches but.....some points I want to say.
    > >
    > > 1. No more conflict with Ying's work ?
    > >    Could you explain what she has and what you don't in this v2 ?
    > >    If Ying's one has something good to be merged to your set, please
    > > include it.
    >
    > My patch I sent out last time was doing rework of soft_limit reclaim.
    > It convert the RB-tree based to
    > a linked list round-robin fashion of all memcgs across their soft
    > limit per-zone.
    >
    > I will apply this patch and try to test it. After that i will get
    > better idea whether or not it is being covered here.

    Thanks!!

    > > 4. This work can be splitted into some small works.
    > >     a) fix for current code and clean ups
    >
    > >     a') statistics
    >
    > >     b) soft limit rework
    >
    > >     c) change global reclaim
    >
    > My last patchset starts with a patch reverting the RB-tree
    > implementation of the soft_limit
    > reclaim, and then the new round-robin implementation comes on the
    > following patches.
    >
    > I like the ordering here, and that is consistent w/ the plan we
    > discussed earlier in LSF. Changing
    > the global reclaim would be the last step when the changes before that
    > have been well understood
    > and tested.
    >
    > Sorry If that is how it is done here. I will read through the patchset.

    It's not. The way I implemented soft limits depends on global reclaim
    performing hierarchical reclaim. I don't see how I can reverse the
    order with this dependency.
    --
    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: 2011-06-02 09:53    [W:0.058 / U:90.980 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site