Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932276AbVI3TQc (ORCPT ); Fri, 30 Sep 2005 15:16:32 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932583AbVI3TQb (ORCPT ); Fri, 30 Sep 2005 15:16:31 -0400 Received: from amsfep17-int.chello.nl ([213.46.243.15]:65324 "EHLO amsfep17-int.chello.nl") by vger.kernel.org with ESMTP id S932276AbVI3TQb (ORCPT ); Fri, 30 Sep 2005 15:16:31 -0400 Subject: Re: [PATCH 3/7] CART - an advanced page replacement policy From: Peter Zijlstra To: Marcelo Cc: Linux Kernel Mailing List , linux-mm@kvack.org In-Reply-To: <20050930184404.GA16812@xeon.cnet> References: <20050929180845.910895444@twins> <20050929181622.780879649@twins> <20050930184404.GA16812@xeon.cnet> Content-Type: text/plain Date: Fri, 30 Sep 2005 21:16:20 +0200 Message-Id: <1128107781.14695.32.camel@twins> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3227 Lines: 84 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 > > > > 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 @@ > > > > > +#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 - 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/