On Wed, Apr 22, 2015 at 4:40 PM, Mathieu Desnoyers <mathieu.desnoy...@efficios.com> wrote: > ----- Original Message ----- >> On Fri, Apr 17, 2015 at 11:06 AM, Mathieu Desnoyers >> <mathieu.desnoy...@efficios.com> wrote: >> > diff --git a/init/Kconfig b/init/Kconfig >> > index f5dbc6d..89bad6a 100644 >> > --- a/init/Kconfig >> > +++ b/init/Kconfig >> > @@ -1559,6 +1559,19 @@ config PCI_QUIRKS >> > bugs/quirks. Disable this only if your target machine is >> > unaffected by PCI quirks. >> > >> > +config MEMBARRIER >> > + bool "Enable membarrier() system call" if EXPERT >> > + default y >> > + depends on SMP >> > + help >> > + Enable the membarrier() system call that allows issuing memory >> > + barriers across all running threads, which can be used to >> > distribute >> > + the cost of user-space memory barriers asymmetrically by >> > transforming >> > + pairs of memory barriers into pairs consisting of membarrier() >> > and a >> > + compiler barrier. >> > + >> > + If unsure, say Y. >> > + >> >> I understand why this syscall makes sense on SMP only, but you are >> anyways checking num_online_cpus() and returning if it is only one. Is >> this limitation necessary then? How do !SMP systems handle this >> syscall? (I am guessing glibc wrapper?) > > For !SMP, this system call is not implemented (returns -ENOSYS). > Userspace libs are expected to query sysconf(_SC_NPROCESSORS_CONF) > and check whether the system supports multiprocessor at all. If > only a single processor is supported by the kernel, then userspace > can skip the calls to sys_membarrier altogether, because they are > not even needed. > > Do you think this kind of information belongs in a man page ? > > Should we instead just implement the system call in !SMP, and > return 0 without any side-effect ? This would be a bit inefficient > to let userspace call a system call that has no effect whatsoever. >
Are there any other SMP-only system calls like this? I am not really sure what is the right way but documenting it would be good. -- Pranith -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
