From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 02/10] ARM: tlb: don't perform inner-shareable invalidation for local TLB ops
Date: Tue, 18 Jun 2013 12:32:37 +0100 [thread overview]
Message-ID: <20130618113237.GC5893@mudshark.cambridge.arm.com> (raw)
In-Reply-To: <51BA064B.7010204@arm.com>
On Thu, Jun 13, 2013 at 06:50:03PM +0100, Jonathan Austin wrote:
> Hi Will,
Hi Jonny,
> On 06/06/13 15:28, Will Deacon wrote:
> > Inner-shareable TLB invalidation is typically more expensive than local
> > (non-shareable) invalidation, so performing the broadcasting for
> > local_flush_tlb_* operations is a waste of cycles and needlessly
> > clobbers entries in the TLBs of other CPUs.
> >
> > This patch introduces __flush_tlb_* versions for many of the TLB
> > invalidation functions, which only respect inner-shareable variants of
> > the invalidation instructions. This allows us to modify the v7 SMP TLB
> > flags to include *both* inner-shareable and non-shareable operations and
> > then check the relevant flags depending on whether the operation is
> > local or not.
>
> I think this approach leaves us in trouble for some SMP_ON_UP cores as
> the IS versions of the instructions don't exist for them.
>
> Is there something that should be ensuring your new __flush_tlb*
> functions don't get called for SMP_ON_UP? If not it looks like we might
> need to do some runtime patching with the ALT_SMP/ALT_UP macros...
Well spotted. Actually, the best fix here is no honour the tlb flags we end
up with, since they get patched by the SMP_ON_UP code (which forces
indirection via MULTI_TLB). We should extract the `meat' of the local_ ops
into __local_ops, which can be inlined directly into the non-local variants
without introducing additional barriers around the invalidation operations.
> A follow on question is whether we still need to keep the *non* unified
> TLB maintenance operations (eg DTLBIALL, ITLBIALL). As far as I can see
> looking in to old TRMs, the last ARM CPU that didn't automatically treat
> those I/D ops to unified ones was ARM10, so not relevant here...
My reading of the 1136 TRM is that there are separate micro-tlbs and a
unified main tlb. I don't see any implication that an operation on the
unified tlb automatically applies to both micro-tlbs, but I've not checked
the rtl (the implication holds the other way around).
Will
next prev parent reply other threads:[~2013-06-18 11:32 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-06 14:28 [PATCH 00/10] Make use of v7 barrier variants in Linux Will Deacon
2013-06-06 14:28 ` [PATCH 01/10] ARM: mm: remove redundant dsb() prior to range TLB invalidation Will Deacon
2013-06-06 14:28 ` [PATCH 02/10] ARM: tlb: don't perform inner-shareable invalidation for local TLB ops Will Deacon
2013-06-13 17:50 ` Jonathan Austin
2013-06-18 11:32 ` Will Deacon [this message]
2013-06-06 14:28 ` [PATCH 03/10] ARM: tlb: don't bother with barriers for branch predictor maintenance Will Deacon
2013-06-06 14:28 ` [PATCH 04/10] ARM: tlb: don't perform inner-shareable invalidation for local BP ops Will Deacon
2013-06-06 14:28 ` [PATCH 05/10] ARM: barrier: allow options to be passed to memory barrier instructions Will Deacon
2013-06-06 14:28 ` [PATCH 06/10] ARM: spinlock: use inner-shareable dsb variant prior to sev instruction Will Deacon
2013-06-06 14:28 ` [PATCH 07/10] ARM: mm: use inner-shareable barriers for TLB and user cache operations Will Deacon
2013-06-06 14:28 ` [PATCH 08/10] ARM: tlb: reduce scope of barrier domains for TLB invalidation Will Deacon
2013-06-06 14:28 ` [PATCH 09/10] ARM: kvm: use inner-shareable barriers after TLB flushing Will Deacon
2013-06-06 14:28 ` [PATCH 10/10] ARM: mcpm: use -st dsb option prior to sev instructions Will Deacon
2013-06-07 4:15 ` Nicolas Pitre
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=20130618113237.GC5893@mudshark.cambridge.arm.com \
--to=will.deacon@arm.com \
--cc=linux-arm-kernel@lists.infradead.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).