From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Andreas Mohr <andi@rhlx01.fht-esslingen.de>
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 12:10:16 +1000 [thread overview]
Message-ID: <448F7008.3010702@yahoo.com.au> (raw)
In-Reply-To: <20060613195352.GA24167@rhlx01.fht-esslingen.de>
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.
>
>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-13 19:33:22.000000000 +0200
>@@ -388,9 +388,11 @@
> */
> send_IPI_mask(cpumask, INVALIDATE_TLB_VECTOR);
>
>- while (!cpus_empty(flush_cpumask))
>+ while (!cpus_empty(flush_cpumask)) {
>+ cpu_relax();
> /* nothing. lockup detection does not belong here */
> mb();
>+ }
>
> flush_mm = NULL;
> flush_va = 0;
>
Send instant messages to your online friends http://au.messenger.yahoo.com
next prev parent reply other threads:[~2006-06-14 2:10 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 ` Nick Piggin [this message]
2006-06-14 19:32 ` [PATCH -mm] i386: cpu_relax() smp.c Andreas Mohr
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=448F7008.3010702@yahoo.com.au \
--to=nickpiggin@yahoo.com.au \
--cc=akpm@osdl.org \
--cc=andi@rhlx01.fht-esslingen.de \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
/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.