Re: [RFC PATCH] introduce sys_membarrier(): process-wide memory barrier (v5)

Mathieu Desnoyers
2010-01-13T14:38:11Z

* Nicholas Miell (nmiell@comcast.net) wrote:
> On Tue, 2010-01-12 at 21:31 -0800, Paul E. McKenney wrote:
> > 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
>
> Because the behavior is still correct, even if it is slower than you'd
> expect. It doesn't really matter where the expedited flag goes, though,
> because every future kernel will understand it.

16ms vs few µs is such a huge performance difference that it's barely
adequate to say that the behavior is still correct, but we definitely
cannot say it is unchanged. It can really render some applications
unusable.

If, for some reason, the expedited version of the system call happens to
be unimplemented, we should return -EINVAL, so the application can deal
with it in the approproate way (which could be, for instance, to use a
fall-back doing memory barriers on the RCU read-side).

But I don't see any reason for not implementing the expedited version
properly in the first place.

Thanks,

Mathieu

>
> --
> Nicholas Miell <nmiell@comcast.net>
>

--
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68