[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140409082008.GA10526@twins.programming.kicks-ass.net>
Date: Wed, 9 Apr 2014 10:20:08 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Madhavan Srinivasan <maddy@...ux.vnet.ibm.com>
Cc: Dave Hansen <dave.hansen@...el.com>, linux-kernel@...r.kernel.org,
linuxppc-dev@...ts.ozlabs.org, linux-mm@...ck.org,
linux-arch@...r.kernel.org, x86@...nel.org,
benh@...nel.crashing.org, paulus@...ba.org,
kirill.shutemov@...ux.intel.com, rusty@...tcorp.com.au,
akpm@...ux-foundation.org, riel@...hat.com, mgorman@...e.de,
ak@...ux.intel.com, mingo@...nel.org
Subject: Re: [PATCH V2 1/2] mm: move FAULT_AROUND_ORDER to arch/
On Wed, Apr 09, 2014 at 07:02:02AM +0530, Madhavan Srinivasan wrote:
> On Friday 04 April 2014 09:48 PM, Dave Hansen wrote:
> > On 04/03/2014 11:27 PM, Madhavan Srinivasan wrote:
> >> This patch creates infrastructure to move the FAULT_AROUND_ORDER
> >> to arch/ using Kconfig. This will enable architecture maintainers
> >> to decide on suitable FAULT_AROUND_ORDER value based on
> >> performance data for that architecture. Patch also adds
> >> FAULT_AROUND_ORDER Kconfig element in arch/X86.
> >
> > Please don't do it this way.
> >
> > In mm/Kconfig, put
> >
> > config FAULT_AROUND_ORDER
> > int
> > default 1234 if POWERPC
> > default 4
> >
> > The way you have it now, every single architecture that needs to enable
> > this has to go put that in their Kconfig. That's madness. This way,
>
> I though about it and decided not to do this way because, in future,
> sub platforms of the architecture may decide to change the values. Also,
> adding an if line for each architecture with different sub platforms
> oring to it will look messy.
This still misses out on Ben's objection that its impossible to get this
right at compile time for many kernels, since they can boot and run on
many different subarchs.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists