From: Russell King <rmk+lkml@arm.linux.org.uk>
To: Kevin Hilman <khilman@mvista.com>
Cc: Daniel Walker <dwalker@mvista.com>, Ingo Molnar <mingo@elte.hu>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH -rt] ARM TLB flush fix: don't forget to re-enable preemption
Date: Wed, 23 May 2007 17:25:00 +0100 [thread overview]
Message-ID: <20070523162500.GA1976@flint.arm.linux.org.uk> (raw)
In-Reply-To: <1179936837.7051.11.camel@vence.hilman.org>
On Wed, May 23, 2007 at 09:13:57AM -0700, Kevin Hilman wrote:
> On Wed, 2007-05-23 at 10:22 +0100, Russell King wrote:
> > In which case shouldn't it be at the end of the function so it includes
> > the write buffer handling as well?
> >
> > However, I think I agree with Daniel on this one. I don't see the point
> > of the preempt_disable() here.
>
> Note that my patch simply adds an enable to match the disable added by
> the -rt patch. I'm not sure where the disable originally came from, but
> there are disable/enable pairs scattered throughout tlbflush.h in the
> -rt patch.
>
> If this one isn't necessary, then the others probably are not either.
> In most cases there are 2 mcr instructions inside the critical section.
> One for the dsb() and the other for the actual function.
>
> Russell, is there a reason any of these sections should be atomic?
I don't see any reason for them to be - when switching to another process
we'll generally do a full TLB flush anyway, so what's the point in making
these flushes atomic?
Consider:
flush_tlb_page()
first mcr - invalidates tlb single entry
--- context switch, invalidates entire tlb, inc dsb ---
something else runs
--- context switch, invalidates entire tlb, inc dsb, again ---
dsb
That context switch is harmless - we end up with the entire TLB being
invalidated and a DSB following. Now consider:
flush_tlb_page()
--- context switch, invalidates entire tlb, inc dsb ---
something else runs
--- context switch, invalidates entire tlb, inc dsb, again ---
preempt_disable()
first mcr - invalidates tlb single entry
dsb
preempt_enable()
Any difference? No. Without the preempt disable/enable fiddling? No.
flush_tlb_page()
preempt_disable()
first mcr - invalidates tlb single entry
dsb
preempt_enable()
--- context switch, invalidates entire tlb, inc dsb ---
something else runs
--- context switch, invalidates entire tlb, inc dsb, again ---
Any difference? No. Without the preempt disable/enable fiddling? No.
In every case of a preemption occuring in the middle of a tlb operation,
the ultimate result is identical irrespective of preempt control
sprinkling.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
next prev parent reply other threads:[~2007-05-23 16:25 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-22 23:01 [PATCH -rt] ARM TLB flush fix: don't forget to re-enable preemption Kevin Hilman
2007-05-22 23:25 ` Daniel Walker
2007-05-22 23:41 ` Kevin Hilman
2007-05-22 23:48 ` Daniel Walker
2007-05-23 9:22 ` Russell King
2007-05-23 16:13 ` Kevin Hilman
2007-05-23 16:25 ` Russell King [this message]
2007-05-23 17:31 ` Kevin Hilman
2007-05-23 16:30 ` Daniel Walker
2007-05-23 3:39 ` Thomas Gleixner
2007-05-24 0:41 ` Kevin Hilman
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=20070523162500.GA1976@flint.arm.linux.org.uk \
--to=rmk+lkml@arm.linux.org.uk \
--cc=dwalker@mvista.com \
--cc=khilman@mvista.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
/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.