From: Martin Schwidefsky <schwidefsky@de.ibm.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Russell King <rmk@arm.linux.org.uk>,
linux-arch@vger.kernel.org, davem@davemloft.net,
hugh@veritas.com
Subject: Re: + sparc64-rename-tlb_flush_mmu.patch added to -mm tree
Date: Wed, 18 Jul 2007 09:48:57 +0200 [thread overview]
Message-ID: <1184744937.17915.21.camel@localhost> (raw)
In-Reply-To: <20070717144245.7760a716.akpm@linux-foundation.org>
On Tue, 2007-07-17 at 14:42 -0700, Andrew Morton wrote:
> umm, OK, well what is the spec for this new interface which Martin
> is proposing to add?
Actually the interface is already there but so far it has been internal
to the generic tlb gather code and most architecture variants.
> It _seems_ to be that if the arch implements tlb_flush_mmu() then its
> tlb_finish_mmu() can (should) be a no-op?
Yes, tlb_flush_mmu() can be a no-op, it basically says that "now is a
good time to get rid of the tlbs / pages gathered in the tlb gather
structure so far". In case you have already freed everything
tlb_flush_mmu is naturally a no-op, e.g. for arm.
> Or if the arch's tlb_finish_mmu() does a full mm "flush" (god I hate that
> term - here we meant writeback, and perhaps invalidate??)) then its
> tlb_flush_mmu() can (should) be a no-op.
This is one case where the architecture can flush at the beginning of
the tlb gather operation and tlb_flush_mmu turns into a nop.
There are four difference batched tlb operations:
1) change_protection does a number of ptep_get_and_clear()/set_pte_at()
calls followed by a flush_tlb_range().
2) dup_mmap/copy_page_range does ptep_set_wrprotect() on a choice of
ptes followed by a flush_tlb_mm().
3) unmap_region() and zap_page_range() use the tlb gatherer with
fullmm==0 which will make zap_pte_range() call ptep_get_and_clear_full()
with fullmm==0.
4) exit_map() uses the tlb gatherer with fullmm==1 which will make
zap_pte_range() call ptep_get_and_clear_full() with fullmm==1.
So we have the "full" flush, the partial flush, the wrprotect flush and
the change protection flush. I've been halfway through the code that
introduces the notion of these four different flush types before I gave
up because it resulted in too much code.
> Or something like that. Martin, I'd suggest that an update to
> Documentation/cachetlb.txt is in order, spell this all out.
Ok, I will see what I can do.
> Doing this properly would require that Documentation/cachetlb.txt say
> something about tlb_gather_mmu() and tlb_finish_mmu() too, I guess.
> Please ;)
That is the sore spot, we (I?) have to write documentation for all the
primitives of the tlb gatherer.
--
blue skies,
Martin.
"Reality continues to ruin my life." - Calvin.
next prev parent reply other threads:[~2007-07-18 7:46 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200707170748.l6H7m1so005969@imap1.linux-foundation.org>
[not found] ` <20070717005551.cdb9504e.akpm@linux-foundation.org>
[not found] ` <20070717010324.833fee7e.akpm@linux-foundation.org>
2007-07-17 13:56 ` + sparc64-rename-tlb_flush_mmu.patch added to -mm tree Martin Schwidefsky
2007-07-17 18:18 ` Russell King
2007-07-17 19:08 ` Andrew Morton
2007-07-17 21:14 ` Russell King
2007-07-17 21:42 ` Andrew Morton
2007-07-18 7:48 ` Martin Schwidefsky [this message]
2007-07-17 21:55 ` Luck, Tony
2007-07-17 22:04 ` Russell King
2007-07-17 22:21 ` Luck, Tony
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=1184744937.17915.21.camel@localhost \
--to=schwidefsky@de.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=davem@davemloft.net \
--cc=hugh@veritas.com \
--cc=linux-arch@vger.kernel.org \
--cc=rmk@arm.linux.org.uk \
/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