Re: [PATCH 1/3] vm: kswapd incmin

From: Marcelo Tosatti (marcelo.tosatti_at_cyclades.com)
Date: 11/07/05

  • Next message: don fisher: "Crashes wuth Tyan S2892"
    Date:	Mon, 7 Nov 2005 16:43:06 -0200
    To: Nick Piggin <nickpiggin@yahoo.com.au>
    
    

    On Tue, Nov 08, 2005 at 10:08:53AM +1100, Nick Piggin wrote:
    > Marcelo Tosatti wrote:
    > >Hi Nick,
    > >
    > >Looks nice, much easier to read than before.
    > >
    >
    > Hi Marcelo,
    >
    > Thanks! That was one of the main aims.
    >
    > >One comment: you change the pagecache/slab scanning ratio by moving
    > >shrink_slab() outside of the zone loop.
    > >
    > >This means that for each kswapd iteration will scan "lru_pages"
    > >SLAB entries, instead of "lru_pages*NR_ZONES" entries.
    > >
    > >Can you comment on that?
    > >
    >
    > I believe I have tried to get it right, let me explain. lru_pages
    > is just used as the divisor for the ratio between lru scanning
    > and slab scanning. So long as it is kept constant across calls to
    > shrink_slab, there should be no change in behaviour.
    >
    > The the nr_scanned variable is the other half of the equation that
    > controls slab shrinking. I have changed from:
    >
    > lru_pages = total_node_lru_pages;
    > for each zone in node {
    > shrink_zone();
    > shrink_slab(zone_scanned, lru_pages);
    > }
    >
    > To:
    >
    > lru_pages = 0;
    > for each zone in node {
    > shrink_zone();
    > lru_pages += zone_lru_pages;
    > }
    > shrink_slab(total_zone_scanned, lru_pages);
    >
    > So the ratio remains basically the same
    > [eg. 10/100 + 20/100 + 30/100 = (10+20+30)/100]
    >
    > 2 reasons for doing this. The first is just efficiency and better
    > rounding of the divisions.
    >
    > The second is that within the for_each_zone loop, we are able to
    > set all_unreclaimable without worrying about slab, because the
    > final shrink_slab at the end will clear all_unreclaimable if any
    > zones have had slab pages freed up.
    >
    > I believe it generally should result in more consistent reclaim
    > across zones, and also matches direct reclaim better.
    >
    > Hope this made sense,

    Yes, makes sense. My reading was not correct.

    Sounds great.
    -
    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/


  • Next message: don fisher: "Crashes wuth Tyan S2892"

    Relevant Pages

    • Re: [PATCH 1/3] vm: kswapd incmin
      ... Marcelo Tosatti wrote: ... > shrink_slaboutside of the zone loop. ... controls slab shrinking. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [PATCH 0/4] Swap migration V3: Overview
      ... Marcelo Tosatti wrote: ... > number of pages to reclaim also relative to zone size. ... we run DMA-zone reclaim half as often - it should balance out. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [PATCH 0/5] make slab gfp fair
      ... If the boundaries would be fluid then we would not need cpusets. ... ZONE_NORMAL slab can exhaust memory available for ZONE_DMA. ... Again the question is the watermarks of which zone? ... ZONE_NORMAL allocation you have 3 to pick from. ...
      (Linux-Kernel)
    • Re: Freeze
      ... >> this code path, the slabzone would get a new slab for each calling thread, ... > They will not flood the system with allocation requests. ... even if it is for the same zone. ...
      (freebsd-current)
    • [patch 18/67] zone_reclaim: dynamic slab reclaim
      ... Currently one can enable slab reclaim by setting an explicit option in ... that means that the slab can grow excessively and that most memory ... This patch implements slab reclaim during zone reclaim. ...
      (Linux-Kernel)