From: Rusty Russell <rusty@rustcorp.com.au>
To: Dave Hansen <dave.hansen@intel.com>,
Madhavan Srinivasan <maddy@linux.vnet.ibm.com>,
linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
linux-mm@kvack.org, linux-arch@vger.kernel.org, x86@kernel.org
Cc: benh@kernel.crashing.org, paulus@samba.org,
kirill.shutemov@linux.intel.com, akpm@linux-foundation.org,
riel@redhat.com, mgorman@suse.de, ak@linux.intel.com,
peterz@infradead.org, mingo@kernel.org
Subject: Re: [PATCH V2 1/2] mm: move FAULT_AROUND_ORDER to arch/
Date: Tue, 22 Apr 2014 16:52:17 +0930 [thread overview]
Message-ID: <87vbu1hlqu.fsf@rustcorp.com.au> (raw)
In-Reply-To: <53456B61.1040901@intel.com>
Dave Hansen <dave.hansen@intel.com> writes:
> On 04/08/2014 06:32 PM, Madhavan Srinivasan wrote:
>>> > 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.
>
> I'm not sure why I'm trying here any more. You do seem quite content to
> add as much cruft to ppc and every other architecture as possible. If
> your theoretical scenario pops up, you simply do this in ppc:
>
> config ARCH_FAULT_AROUND_ORDER
> int
> default 999
> default 888 if OTHER_SILLY_POWERPC_SUBARCH
>
> But *ONLY* in the architectures that care about doing that stuff. You
> leave every other architecture on the planet alone. Then, in mm/Kconfig:
>
> config FAULT_AROUND_ORDER
> int
> default ARCH_FAULT_AROUND_ORDER if ARCH_FAULT_AROUND_ORDER
> default 4
>
> Your way still requires going and individually touching every single
> architecture's Kconfig that wants to enable fault around. That's not an
> acceptable solution.
Why bother with Kconfig at all? It seems like a weird indirection.
And talking about future tuning seems like a separate issue, if and when
someone does the work. For the moment, let's keep it simple (as below).
If you really want Kconfig, then just go straight from
ARCH_FAULT_AROUND_ORDER, ie:
#ifdef CONFIG_ARCH_FAULT_AROUND_ORDER
#define FAULT_AROUND_ORDER CONFIG_ARCH_FAULT_AROUND_ORDER
#else
#define FAULT_AROUND_ORDER 4
#endif
Then powerpc's Kconfig defines CONFIG_ARCH_FAULT_AROUND_ORDER, and
we're done.
Cheers,
Rusty.
diff --git a/arch/powerpc/include/asm/page.h b/arch/powerpc/include/asm/page.h
index 32e4e212b9c1..b519c5c53cfc 100644
--- a/arch/powerpc/include/asm/page.h
+++ b/arch/powerpc/include/asm/page.h
@@ -412,4 +412,7 @@ typedef struct page *pgtable_t;
#include <asm-generic/memory_model.h>
#endif /* __ASSEMBLY__ */
+/* Measured on a 4 socket Power7 system (128 Threads and 128GB memory) */
+#define FAULT_AROUND_ORDER 3
+
#endif /* _ASM_POWERPC_PAGE_H */
diff --git a/mm/memory.c b/mm/memory.c
index d0f0bef3be48..9aa47e9ec7ba 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -3382,7 +3382,10 @@ void do_set_pte(struct vm_area_struct *vma, unsigned long address,
update_mmu_cache(vma, address, pte);
}
+/* Archs can override, but this seems to work for x86. */
+#ifndef FAULT_AROUND_ORDER
#define FAULT_AROUND_ORDER 4
+#endif
#ifdef CONFIG_DEBUG_FS
static unsigned int fault_around_order = FAULT_AROUND_ORDER;
next prev parent reply other threads:[~2014-04-22 7:39 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-04 6:27 [PATCH V2 0/2] FAULT_AROUND_ORDER patchset performance data for powerpc Madhavan Srinivasan
2014-04-04 6:27 ` [PATCH V2 1/2] mm: move FAULT_AROUND_ORDER to arch/ Madhavan Srinivasan
2014-04-04 13:17 ` Kirill A. Shutemov
2014-04-09 1:14 ` Madhavan Srinivasan
2014-04-04 16:18 ` Dave Hansen
2014-04-04 17:50 ` David Miller
2014-04-09 1:44 ` Madhavan Srinivasan
2014-04-07 5:45 ` Benjamin Herrenschmidt
2014-04-09 1:32 ` Madhavan Srinivasan
2014-04-09 8:20 ` Peter Zijlstra
2014-04-09 15:48 ` Dave Hansen
2014-04-10 8:29 ` Madhavan Srinivasan
2014-04-09 15:46 ` Dave Hansen
2014-04-22 7:22 ` Rusty Russell [this message]
2014-04-04 6:27 ` [PATCH V2 2/2] mm: add FAULT_AROUND_ORDER Kconfig paramater for powerpc Madhavan Srinivasan
2014-04-04 7:02 ` Ingo Molnar
2014-04-04 7:10 ` Ingo Molnar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87vbu1hlqu.fsf@rustcorp.com.au \
--to=rusty@rustcorp.com.au \
--cc=ak@linux.intel.com \
--cc=akpm@linux-foundation.org \
--cc=benh@kernel.crashing.org \
--cc=dave.hansen@intel.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=maddy@linux.vnet.ibm.com \
--cc=mgorman@suse.de \
--cc=mingo@kernel.org \
--cc=paulus@samba.org \
--cc=peterz@infradead.org \
--cc=riel@redhat.com \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).