Re: [PATCH 3/7] CART - an advanced page replacement policy

From: Peter Zijlstra (a.p.zijlstra_at_chello.nl)
Date: 09/30/05

  • Next message: dpervushin_at_gmail.com: "RE: [PATCH] SPI"
    To: Marcelo <marcelo.tosatti@cyclades.com>
    Date:	Fri, 30 Sep 2005 21:16:20 +0200
    
    

    On Fri, 2005-09-30 at 15:44 -0300, Marcelo wrote:
    > Hi Peter,
    >
    > On Thu, Sep 29, 2005 at 08:08:48PM +0200, Peter Zijlstra wrote:
    > > The flesh of the CART implementation. Again comments in the file should be
    > > clear.
    >
    > Having per-zone "B1" target accounted at fault-time instead of a global target
    > strikes me.
    >
    > The ARC algorithm adjusts the B1 target based on the fact that being-faulted-pages
    > were removed from the same memory region where such pages will reside.
    >
    > The per-zone "B1" target as you implement it means that the B1 target accounting
    > happens for the zone in which the page for the faulting data has been allocated,
    > _not_ on the zone from which the data has been evicted. Seems quite unfair.
    >
    > So for example, if a page gets removed from the HighMem zone while in the
    > B1 list, and the same data gets faulted in later on a page from the normal
    > zone, Normal will have its "B1" target erroneously increased.
    >
    > A global inactive target scaled to the zone size would get rid of that problem.

    Good, good, I'll think this though, this probably means the other
    targets: 'p' and 'r' would similarly benefit.

    > Another issue is testing: You had some very interesting numbers before,
    > how are things now?

    I managed to reproduce that 10% gain on the kernel build time once more,
    however it seems very unstable, I generally get only 2-3%.

    > > Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
    > >
    > > mm/cart.c | 631 +++++++++++++++++++++++++++++++++++++++++++++
    > > 7 files changed, 682 insertions(+), 35 deletions(-)
    > >
    > > Index: linux-2.6-git/mm/cart.c
    > > ===================================================================
    > > --- /dev/null
    > > +++ linux-2.6-git/mm/cart.c
    > > @@ -0,0 +1,639 @@
    >
    > <snip>
    >
    > > +#define cart_cT ((zone)->nr_active + (zone)->nr_inactive + (zone)->free_pages)
    > > +#define cart_cB ((zone)->present_pages)
    > > +
    > > +#define T2B(x) (((x) * cart_cB) / cart_cT)
    > > +#define B2T(x) (((x) * cart_cT) / cart_cB)
    > > +
    > > +#define size_T1 ((zone)->nr_active)
    > > +#define size_T2 ((zone)->nr_inactive)
    > > +
    > > +#define list_T1 (&(zone)->active_list)
    > > +#define list_T2 (&(zone)->inactive_list)
    > > +
    > > +#define cart_p ((zone)->nr_p)
    > > +#define cart_q ((zone)->nr_q)
    > > +
    > > +#define size_B1 ((zone)->nr_evicted_active)
    > > +#define size_B2 ((zone)->nr_evicted_inactive)
    > > +
    > > +#define nr_Ns ((zone)->nr_shortterm)
    > > +#define nr_Nl (size_T1 + size_T2 - nr_Ns)
    >
    > These defines are not not easy to read inside the code which
    > uses them, I personally think that "zone->nr_.." explicitly is
    > much clearer.

    Yes, I plan to replace them by explicit referenced, however they were
    handy while playing with the definitions. And since nobody outside of
    the cart code still refers to them I plan to rename the struct zone
    members to match these names; zone->nr_active to zone->size_T1 and
    zone->active_list to zone->list_T1.

    -- 
    Peter Zijlstra <a.p.zijlstra@chello.nl>
    -
    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: dpervushin_at_gmail.com: "RE: [PATCH] SPI"

    Relevant Pages

    • Re: [PATCH 0/5] Reducing fragmentation using zones
      ... I was curious if you could repost those with the other benchmarks for a 3 way comparison. ... The simplified version got rid of a lot of the complexity people were complaining about and in my mind still seems like preferable direction. ... There are lots of workloads that "reasonable" defaults for a zone based approach would cause the system to regress terribly. ... To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ ...
      (Linux-Kernel)
    • Re: [Lhms-devel] [PATCH 0/7] Fragmentation Avoidance V19
      ... > awful lot of complexity to some of these code paths yourself ... ... >>goes in that zone. ... then the frag patches can't guarantee anything either. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: swsusp with highmem, testing wanted
      ... static int pfn_is_nosave ... static void free_suspend_pagedir_zone(struct zone *zone, ... When do you have a heart between your knees? ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • [patch 7/14] mm: remove bad_range
      ... +static inline int bad_range(struct zone *zone, ... Send instant messages to your online friends http://au.messenger.yahoo.com ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [PATCH] Permit inode & dentry hash tables to be allocated > MAX_ORDER size
      ... > We've hit a problem with alignment issues where the start of the zone is ... Andy sent me a patch this morning to throw away ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)