Messages in this thread | | | Date | Tue, 12 Jan 2010 21:31:26 -0800 | From | "Paul E. McKenney" <> | Subject | Re: [RFC PATCH] introduce sys_membarrier(): process-wide memory barrier (v5) |
| |
On Tue, Jan 12, 2010 at 09:00:23PM -0800, Nicholas Miell wrote: > On Tue, 2010-01-12 at 20:37 -0500, Mathieu Desnoyers wrote: > > + * sys_membarrier - issue memory barrier on current process running threads > > + * @expedited: (0) Lowest overhead. Few milliseconds latency. > > + * (1) Few microseconds latency. > > + * > > Alternate ABI proposal, keeping the possibility of future expansion in > mind: > > /* > Mandatory flags to the membarrier system call that the kernel must > understand are in the high 16 bits. > */ > #define MEMBARRIER_MANDATORY_MASK 0xFFFF0000 > > /* > Optional hints that the kernel can ignore are in the low 16 bits. > */ > #define MEMBARRIER_OPTIONAL_MASK 0x0000FFFF > > #define MEMBARRIER_EXPEDITED 1 > > extern int membarrier(unsigned int flags); > > And then add to the system call itself: > > if ((flags & MEMBARRIER_MANDATORY_MASK) != 0) > return -EINVAL;
Why is it OK to ignore the developer's request for an expedited membarrer()? The guy who expected the syscall to complete in a few microseconds might not be so happy to have it take many milliseconds. By the same token, the guy who specified non-expedited so as to minimally disturb other threads in the system might not be so happy to see them all be IPIed for no good reason. ;-)
Thanx, Paul
| |