From: Linus Torvalds <torvalds@linux-foundation.org>
To: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
linux-mm@kvack.org, Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@elte.hu>,
akpm@linux-foundation.org, Rik van Riel <riel@redhat.com>,
Hugh Dickins <hugh.dickins@tiscali.co.uk>,
Mel Gorman <mel@csn.ul.ie>, Nick Piggin <npiggin@kernel.dk>,
Alex Shi <alex.shi@intel.com>,
"Nikunj A. Dadhania" <nikunj@linux.vnet.ibm.com>,
Konrad Rzeszutek Wilk <konrad@darnok.org>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
David Miller <davem@davemloft.net>,
Russell King <rmk@arm.linux.org.uk>,
Catalin Marinas <catalin.marinas@arm.com>,
Chris Metcalf <cmetcalf@tilera.com>,
Martin Schwidefsky <schwidefsky@de.ibm.com>,
Tony Luck <tony.luck@intel.com>, Paul Mundt <lethal@linux-sh.org>,
Jeff Dike <jdike@addtoit.com>,
Richard Weinberger <richard@nod.at>,
Hans-Christian Egtvedt <hans-christian.egtvedt@atmel.com>,
Ralf Baechle <ralf@linux-mips.org>,
Kyle McMartin <kyle@mcmartin.ca>,
James Bottomley <jejb@parisc-linux.org>,
Chris Zankel <chris@zankel.net>
Subject: Re: [PATCH 02/20] mm: Add optional TLB flush to generic RCU page-table freeing
Date: Wed, 27 Jun 2012 15:23:28 -0700 [thread overview]
Message-ID: <CA+55aFwa41fzvx8EZG_gODvw7hSpr+iP+w5fXp6jUcQh-4nFgQ@mail.gmail.com> (raw)
In-Reply-To: <20120627212830.693232452@chello.nl>
On Wed, Jun 27, 2012 at 2:15 PM, Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:
>
> Certain architectures (viz. x86, arm, s390) have hardware page-table
> walkers (#PF). So during the RCU page-table teardown process make sure
> we do a tlb flush of page-table pages on all relevant CPUs to
> synchronize against hardware walkers, and then free the pages.
NACK.
Why would hw page table walkers be that special? Plus your config
option is horribly done anyway, where you do it as some kind of
"default y" and then have complex conditionals on it.
Plus it really isn't about hardware page table walkers at all. It's
more about the possibility of speculative TLB fils, it has nothing to
do with *how* they are done. Sure, it's likely that a software
pagetable walker wouldn't be something that gets called speculatively,
but it's not out of the question.
So I think your config option is totally mis-designed and actively
misleading. It's also horrible from a design standpoint, since it's
entirely possible that some day POWERPC will actually see the light
and do speculative TLB fills etc.
So *if* this needs to be done, it needs to be done right. That means:
- don't talk about HW walking, since it's not about that
- don't say "if you have speculative walkers", and use an ifndef. Say
"If you can *guarantee* that nothing else walks page tables
speculatively, and we have only one thread that owns the mmu, and that
one thread is us, *then* we can do this optimization". So switch the
config option around.
- make it a per-architecture thing to say "I guarantee that I never
fill the TLB speculatively". Don't do that "default y" with complex
conditionals crap.
IOW, if Sparc/PPC really want to guarantee that they never fill TLB
entries speculatively, and that if we are in a kernel thread they will
*never* fill the TLB with anything else, then make them enable
CONFIG_STRICT_TLB_FILL or something in their architecture Kconfig
files.
Not like this patch. And not with the misleading names and comments.
Linus
--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2012-06-27 22:23 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-27 21:15 [PATCH 00/20] Unify TLB gather implementations -v3 Peter Zijlstra
2012-06-27 21:15 ` [PATCH 01/20] mm, x86: Add HAVE_RCU_TABLE_FREE support Peter Zijlstra
2012-06-27 21:15 ` [PATCH 02/20] mm: Add optional TLB flush to generic RCU page-table freeing Peter Zijlstra
2012-06-27 22:23 ` Linus Torvalds [this message]
2012-06-27 23:01 ` Peter Zijlstra
2012-06-27 23:42 ` Linus Torvalds
2012-06-28 7:09 ` Benjamin Herrenschmidt
2012-06-28 11:05 ` Peter Zijlstra
2012-06-28 12:00 ` Benjamin Herrenschmidt
2012-07-24 5:12 ` Nikunj A Dadhania
2012-06-27 21:15 ` [PATCH 03/20] mm, tlb: Remove a few #ifdefs Peter Zijlstra
2012-06-27 21:15 ` [PATCH 04/20] mm, s390: use generic RCU page-table freeing code Peter Zijlstra
2012-06-27 21:15 ` [PATCH 05/20] mm, powerpc: Dont use tlb_flush for external tlb flushes Peter Zijlstra
2012-06-27 21:15 ` [PATCH 06/20] mm, sparc64: " Peter Zijlstra
2012-06-27 21:15 ` [PATCH 07/20] mm, arch: Remove tlb_flush() Peter Zijlstra
2012-06-27 21:15 ` [PATCH 08/20] mm: Optimize fullmm TLB flushing Peter Zijlstra
2012-06-27 22:26 ` Linus Torvalds
2012-06-27 23:02 ` Peter Zijlstra
2012-06-27 23:13 ` Peter Zijlstra
2012-06-27 23:23 ` Linus Torvalds
2012-06-27 23:33 ` Linus Torvalds
2012-06-28 9:16 ` Catalin Marinas
2012-06-28 10:39 ` Benjamin Herrenschmidt
2012-06-28 10:59 ` Peter Zijlstra
2012-06-28 14:53 ` Catalin Marinas
2012-06-28 16:20 ` Peter Zijlstra
2012-06-28 16:38 ` Peter Zijlstra
2012-06-28 16:45 ` Linus Torvalds
2012-06-28 16:52 ` Peter Zijlstra
2012-06-28 21:57 ` Benjamin Herrenschmidt
2012-06-28 21:58 ` Benjamin Herrenschmidt
2012-06-29 8:49 ` Peter Zijlstra
2012-06-29 15:26 ` Catalin Marinas
2012-06-29 22:11 ` Benjamin Herrenschmidt
2012-06-28 10:55 ` Peter Zijlstra
2012-06-28 11:19 ` Martin Schwidefsky
2012-06-28 11:30 ` Peter Zijlstra
2012-06-28 16:00 ` Avi Kivity
2012-06-27 21:15 ` [PATCH 09/20] mm, arch: Add end argument to p??_free_tlb() Peter Zijlstra
2012-06-27 21:15 ` [PATCH 10/20] mm: Provide generic range tracking and flushing Peter Zijlstra
2012-06-27 21:15 ` [PATCH 11/20] mm, s390: Convert to use generic mmu_gather Peter Zijlstra
2012-06-27 22:13 ` Peter Zijlstra
2012-06-28 7:13 ` Martin Schwidefsky
2012-06-27 21:15 ` [PATCH 12/20] mm, arm: Convert arm to generic tlb Peter Zijlstra
2012-06-27 21:15 ` [PATCH 13/20] mm, ia64: Convert ia64 " Peter Zijlstra
2012-06-27 21:15 ` [PATCH 14/20] mm, sh: Convert sh " Peter Zijlstra
2012-06-28 18:32 ` Paul Mundt
2012-06-28 20:27 ` Peter Zijlstra
2012-06-27 21:15 ` [PATCH 15/20] mm, um: Convert um " Peter Zijlstra
2012-06-27 21:15 ` [PATCH 16/20] mm, avr32: Convert avr32 " Peter Zijlstra
2012-06-27 21:15 ` [PATCH 17/20] mm, mips: Convert mips " Peter Zijlstra
2012-06-27 21:15 ` [PATCH 18/20] mm, parisc: Convert parisc " Peter Zijlstra
2012-06-27 21:15 ` [PATCH 19/20] mm, sparc32: Convert sparc32 " Peter Zijlstra
2012-06-27 21:16 ` [PATCH 20/20] mm, xtensa: Convert xtensa " Peter Zijlstra
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=CA+55aFwa41fzvx8EZG_gODvw7hSpr+iP+w5fXp6jUcQh-4nFgQ@mail.gmail.com \
--to=torvalds@linux-foundation.org \
--cc=a.p.zijlstra@chello.nl \
--cc=akpm@linux-foundation.org \
--cc=alex.shi@intel.com \
--cc=benh@kernel.crashing.org \
--cc=catalin.marinas@arm.com \
--cc=chris@zankel.net \
--cc=cmetcalf@tilera.com \
--cc=davem@davemloft.net \
--cc=hans-christian.egtvedt@atmel.com \
--cc=hugh.dickins@tiscali.co.uk \
--cc=jdike@addtoit.com \
--cc=jejb@parisc-linux.org \
--cc=konrad@darnok.org \
--cc=kyle@mcmartin.ca \
--cc=lethal@linux-sh.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mel@csn.ul.ie \
--cc=mingo@elte.hu \
--cc=nikunj@linux.vnet.ibm.com \
--cc=npiggin@kernel.dk \
--cc=ralf@linux-mips.org \
--cc=richard@nod.at \
--cc=riel@redhat.com \
--cc=rmk@arm.linux.org.uk \
--cc=schwidefsky@de.ibm.com \
--cc=tglx@linutronix.de \
--cc=tony.luck@intel.com \
/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