From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter Zijlstra Subject: Re: [PATCH 09/25] ia64: Preemptible mmu_gather Date: Tue, 25 Jan 2011 21:22:23 +0100 Message-ID: <1295986943.28776.1108.camel@laptop> References: <20110125173111.720927511@chello.nl> <20110125174907.664402563@chello.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: Sender: owner-linux-mm@kvack.org To: Tony Luck Cc: Andrea Arcangeli , Avi Kivity , Thomas Gleixner , Rik van Riel , Ingo Molnar , akpm@linux-foundation.org, Linus Torvalds , linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, linux-mm@kvack.org, Benjamin Herrenschmidt , David Miller , Hugh Dickins , Mel Gorman , Nick Piggin , Paul McKenney , Yanmin Zhang List-Id: linux-arch.vger.kernel.org On Tue, 2011-01-25 at 12:12 -0800, Tony Luck wrote: > On Tue, Jan 25, 2011 at 9:31 AM, Peter Zijlstra = wrote: > > struct mmu_gather { > > struct mm_struct *mm; > > unsigned int nr; /* =3D=3D ~0U =3D> fast = mode */ > > + unsigned int max; > > unsigned char fullmm; /* non-zero means full m= m flush */ > > unsigned char need_flush; /* really unmapped some = PTEs? */ > > unsigned long start_addr; > > unsigned long end_addr; > > - struct page *pages[FREE_PTE_NR]; > > + struct page **pages; > > + struct page *local[8]; > > }; >=20 > Overall it looks OK - builds, boots & runs too. One question about > the above bit ... why "8" elements in the local[] array? This ought to b= e > a #define, maybe with a comment explaining the significance. It doesn't > seem to fill out struct mmu_gather to some "nice" size. I can't think > of why batching 8 at a time (in the fallback cannot allocate **pages case= ) > is a good number. So is there some science to the choice, or did you > pluck 8 out of the air?=20 Yeah, pretty much a random number small enough to make struct mmu_gather fit on stack, the reason its not 1 is that a few more entries increase performance a little and freeing more pages increases the chance the page allocation works next time around. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom policy in Canada: sign http://dissolvethecrtc.ca/ Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bombadil.infradead.org ([18.85.46.34]:58577 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751508Ab1AYUWO convert rfc822-to-8bit (ORCPT ); Tue, 25 Jan 2011 15:22:14 -0500 Subject: Re: [PATCH 09/25] ia64: Preemptible mmu_gather From: Peter Zijlstra In-Reply-To: References: <20110125173111.720927511@chello.nl> <20110125174907.664402563@chello.nl> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT Date: Tue, 25 Jan 2011 21:22:23 +0100 Message-ID: <1295986943.28776.1108.camel@laptop> Mime-Version: 1.0 Sender: linux-arch-owner@vger.kernel.org List-ID: To: Tony Luck Cc: Andrea Arcangeli , Avi Kivity , Thomas Gleixner , Rik van Riel , Ingo Molnar , akpm@linux-foundation.org, Linus Torvalds , linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, linux-mm@kvack.org, Benjamin Herrenschmidt , David Miller , Hugh Dickins , Mel Gorman , Nick Piggin , Paul McKenney , Yanmin Zhang Message-ID: <20110125202223.AYBeSwxgU37mmORJwG8sU5ln7BckH-q_G3IgFsRwAoc@z> On Tue, 2011-01-25 at 12:12 -0800, Tony Luck wrote: > On Tue, Jan 25, 2011 at 9:31 AM, Peter Zijlstra wrote: > > struct mmu_gather { > > struct mm_struct *mm; > > unsigned int nr; /* == ~0U => fast mode */ > > + unsigned int max; > > unsigned char fullmm; /* non-zero means full mm flush */ > > unsigned char need_flush; /* really unmapped some PTEs? */ > > unsigned long start_addr; > > unsigned long end_addr; > > - struct page *pages[FREE_PTE_NR]; > > + struct page **pages; > > + struct page *local[8]; > > }; > > Overall it looks OK - builds, boots & runs too. One question about > the above bit ... why "8" elements in the local[] array? This ought to be > a #define, maybe with a comment explaining the significance. It doesn't > seem to fill out struct mmu_gather to some "nice" size. I can't think > of why batching 8 at a time (in the fallback cannot allocate **pages case) > is a good number. So is there some science to the choice, or did you > pluck 8 out of the air? Yeah, pretty much a random number small enough to make struct mmu_gather fit on stack, the reason its not 1 is that a few more entries increase performance a little and freeing more pages increases the chance the page allocation works next time around.