[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1146370149.34873.1429796740391.JavaMail.zimbra@efficios.com>
Date: Thu, 23 Apr 2015 13:45:40 +0000 (UTC)
From: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: Stephen Hemminger <stephen@...workplumber.org>,
Pranith Kumar <bobby.prani@...il.com>,
LKML <linux-kernel@...r.kernel.org>,
Josh Triplett <josh@...htriplett.org>,
KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
Nicholas Miell <nmiell@...cast.net>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Ingo Molnar <mingo@...hat.com>,
Alan Cox <gnomes@...rguk.ukuu.org.uk>,
Lai Jiangshan <laijs@...fujitsu.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Thomas Gleixner <tglx@...utronix.de>,
Peter Zijlstra <peterz@...radead.org>,
David Howells <dhowells@...hat.com>,
Michael Kerrisk <mtk.manpages@...il.com>
Subject: Re: [PATCH v16] sys_membarrier(): system-wide memory barrier
(generic, x86)
----- Original Message -----
> On Wed, 22 Apr 2015 17:40:51 -0700
> Stephen Hemminger <stephen@...workplumber.org> wrote:
>
> > The syscall should just return 0.
> > Let the application not worry about how many CPU's are present
>
> +1
This is indeed how I implemented it initially. The nice thing
about this approach is that if the application don't care much
about the overhead of calling sys_membarrier on !SMP, returning
0 tells the application that sys_membarrier is indeed supported,
and that the application don't need to issue memory barriers on
the other target threads (compiler barrier is then sufficient),
which is correct.
I'll update the patch accordingly.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists