From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: linux-mm@kvack.org, Linux Kernel list <linux-kernel@vger.kernel.org>
Subject: Re: [RFC/PATCH] Use mmu_gather for fork() instead of flush_tlb_mm()
Date: Mon, 09 Jul 2007 17:39:59 +1000 [thread overview]
Message-ID: <4691E64F.5070506@yahoo.com.au> (raw)
In-Reply-To: <1183963544.5961.6.camel@localhost.localdomain>
Benjamin Herrenschmidt wrote:
> Use mmu_gather for fork() instead of flush_tlb_mm()
>
> This patch uses an mmu_gather for copying page tables instead of
> flush_tlb_mm(). This allows archs like ppc32 with hash table to
> avoid walking the page tables a second time to invalidate hash
> entries, and to only flush PTEs that have actually been changed
> from RW to RO.
>
> Note that this contain a small change to the mmu gather stuff,
> it must not call free_pages_and_swap_cache() if no page have been
> queued up for freeing (if we are only invalidating PTEs). Calling
> it on fork can deadlock (I haven't dug why but it looks like a
> good idea to test anyway if we're going to use the mmu_gather for
> more than just removing pages).
>
> If the patch gets accepted, I will split that bit from the rest
> of the patch and send it separately.
>
> The main possible issue I see is with huge pages. Arch code might
> have relied on flush_tlb_mm() and might not cope with
> tlb_remove_tlb_entry() called for huge PTEs.
>
> Other possible issues are if archs make assumptions about
> flush_tlb_mm() being called in fork for different unrelated reasons.
>
> Ah also, we could probably improve the tracking of start/end, in
> the case of lock breaking, the outside function will still finish
> the batch with the entire range. It doesn't matter on ppc and x86
> I think though.
Would it be better off to start off with a new API for this? The
mmu gather I think is traditionally entirely for dealing with
page removal...
--
SUSE Labs, Novell Inc.
WARNING: multiple messages have this Message-ID (diff)
From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: linux-mm@kvack.org, Linux Kernel list <linux-kernel@vger.kernel.org>
Subject: Re: [RFC/PATCH] Use mmu_gather for fork() instead of flush_tlb_mm()
Date: Mon, 09 Jul 2007 17:39:59 +1000 [thread overview]
Message-ID: <4691E64F.5070506@yahoo.com.au> (raw)
In-Reply-To: <1183963544.5961.6.camel@localhost.localdomain>
Benjamin Herrenschmidt wrote:
> Use mmu_gather for fork() instead of flush_tlb_mm()
>
> This patch uses an mmu_gather for copying page tables instead of
> flush_tlb_mm(). This allows archs like ppc32 with hash table to
> avoid walking the page tables a second time to invalidate hash
> entries, and to only flush PTEs that have actually been changed
> from RW to RO.
>
> Note that this contain a small change to the mmu gather stuff,
> it must not call free_pages_and_swap_cache() if no page have been
> queued up for freeing (if we are only invalidating PTEs). Calling
> it on fork can deadlock (I haven't dug why but it looks like a
> good idea to test anyway if we're going to use the mmu_gather for
> more than just removing pages).
>
> If the patch gets accepted, I will split that bit from the rest
> of the patch and send it separately.
>
> The main possible issue I see is with huge pages. Arch code might
> have relied on flush_tlb_mm() and might not cope with
> tlb_remove_tlb_entry() called for huge PTEs.
>
> Other possible issues are if archs make assumptions about
> flush_tlb_mm() being called in fork for different unrelated reasons.
>
> Ah also, we could probably improve the tracking of start/end, in
> the case of lock breaking, the outside function will still finish
> the batch with the entire range. It doesn't matter on ppc and x86
> I think though.
Would it be better off to start off with a new API for this? The
mmu gather I think is traditionally entirely for dealing with
page removal...
--
SUSE Labs, Novell Inc.
--
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:[~2007-07-09 7:40 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-09 3:47 removing flush_tlb_mm as a generic hook ? Benjamin Herrenschmidt
2007-07-09 3:47 ` Benjamin Herrenschmidt
2007-07-09 6:36 ` Benjamin Herrenschmidt
2007-07-09 6:36 ` Benjamin Herrenschmidt
2007-07-09 6:45 ` [RFC/PATCH] Use mmu_gather for fork() instead of flush_tlb_mm() Benjamin Herrenschmidt
2007-07-09 6:45 ` Benjamin Herrenschmidt
2007-07-09 7:39 ` Nick Piggin [this message]
2007-07-09 7:39 ` Nick Piggin
2007-07-09 9:12 ` Benjamin Herrenschmidt
2007-07-09 9:12 ` Benjamin Herrenschmidt
2007-07-09 9:29 ` Nick Piggin
2007-07-09 9:29 ` Nick Piggin
2007-07-09 9:47 ` Benjamin Herrenschmidt
2007-07-09 9:47 ` Benjamin Herrenschmidt
2007-07-09 10:12 ` Nick Piggin
2007-07-09 10:12 ` Nick Piggin
2007-07-09 10:18 ` Nick Piggin
2007-07-09 10:18 ` Nick Piggin
2007-07-09 12:37 ` Benjamin Herrenschmidt
2007-07-09 12:37 ` Benjamin Herrenschmidt
2007-07-09 12:32 ` Benjamin Herrenschmidt
2007-07-09 12:32 ` Benjamin Herrenschmidt
2007-07-09 6:46 ` [RFC/PATCH] Use mmu_gather for /proc stuff " Benjamin Herrenschmidt
2007-07-09 6:46 ` Benjamin Herrenschmidt
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=4691E64F.5070506@yahoo.com.au \
--to=nickpiggin@yahoo.com.au \
--cc=benh@kernel.crashing.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.