From: Andreas Mohr <andi@rhlx01.fht-esslingen.de>
To: Nick Piggin <nickpiggin@yahoo.com.au>
Cc: Andrew Morton <akpm@osdl.org>, Ingo Molnar <mingo@redhat.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH -mm] i386: cpu_relax() smp.c
Date: Wed, 14 Jun 2006 21:32:50 +0200 [thread overview]
Message-ID: <20060614193250.GA20086@rhlx01.fht-esslingen.de> (raw)
In-Reply-To: <448F7008.3010702@yahoo.com.au>
Hi,
On Wed, Jun 14, 2006 at 12:10:16PM +1000, Nick Piggin wrote:
> Andreas Mohr wrote:
>
> >Hi,
> >
> >On Mon, Jun 12, 2006 at 08:37:43PM +0200, Andreas Mohr wrote:
> >
> >>Hi all,
> >>
> >>while reviewing 2.6.17-rc6-mm1, I found some places that might
> >>want to make use of cpu_relax() in order to not block secondary
> >>pipelines while busy-polling (probably especially useful on SMT CPUs):
> >>
> >
> >OK, no replies arguing against anything, thus patch follow-up. ;)
> >(no. 1 of 3)
> >
>
> The other two look fine. This one should remove the mb(). cpu_relax
> IIRC already includes a barrier(), and we are not concerned about
> consistency here, only coherency, which the hardware takes care of
> for us.
>
> The flush_cpumask is guaranteed to be cleared *after* all other
> variables (eg. flush_mm) have been used... that happens in the IPI
> handler of course.
>
> Aside, if we *were* worried about consistency here, smp_mb would
> have been the more correct barrier to use.
Thanks, updated patch to omit mb().
Signed-off-by: Andreas Mohr <andi@lisas.de>
diff -urN linux-2.6.17-rc6-mm2.orig/arch/i386/kernel/smp.c linux-2.6.17-rc6-mm2.my/arch/i386/kernel/smp.c
--- linux-2.6.17-rc6-mm2.orig/arch/i386/kernel/smp.c 2006-06-08 10:38:04.000000000 +0200
+++ linux-2.6.17-rc6-mm2.my/arch/i386/kernel/smp.c 2006-06-14 20:30:46.000000000 +0200
@@ -388,9 +388,10 @@
*/
send_IPI_mask(cpumask, INVALIDATE_TLB_VECTOR);
- while (!cpus_empty(flush_cpumask))
+ while (!cpus_empty(flush_cpumask)) {
/* nothing. lockup detection does not belong here */
- mb();
+ cpu_relax();
+ }
flush_mm = NULL;
flush_va = 0;
next prev parent reply other threads:[~2006-06-14 19:32 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-06-12 18:37 [RFC -mm] more cpu_relax() places? Andreas Mohr
2006-06-13 19:53 ` [PATCH -mm] i386: cpu_relax() smp.c (was: [RFC -mm] more cpu_relax() places?) Andreas Mohr
2006-06-14 2:10 ` [PATCH -mm] i386: cpu_relax() smp.c Nick Piggin
2006-06-14 19:32 ` Andreas Mohr [this message]
2006-06-13 19:54 ` [PATCH -mm] ACPI lock: cpu_relax() (was: [RFC -mm] more cpu_relax() places?) Andreas Mohr
2006-06-14 19:29 ` Andreas Mohr
2006-06-13 19:54 ` [PATCH -mm] x86_64 apic.h " Andreas Mohr
2006-06-14 5:34 ` Andi Kleen
2007-06-14 20:28 ` [PATCH -mm] i386: add cpu_relax() to cmos_lock() Andreas Mohr
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=20060614193250.GA20086@rhlx01.fht-esslingen.de \
--to=andi@rhlx01.fht-esslingen.de \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=nickpiggin@yahoo.com.au \
/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
all inboxes | Powered by JetHome®