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

Mathieu Desnoyers
2010-01-13T18:24:45Z

* Nicholas Miell (nmiell@comcast.net) wrote:
> On Wed, 2010-01-13 at 09:38 -0500, Mathieu Desnoyers wrote:
> > * 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.
> >
>
> You're focusing on the least important detail of the proposal. It
> doesn't matter whether the expedited flag is compat flag or an incompat
> flag, because every version of kernel that ever has the membarrier
> system call will know what it means, and even if for some reason it
> doesn't implement expedited membarriers, it will still be able to
> recognize the flag and return an error.
>
> The whole point of compat and incompat flags is that it allows new
> applications to run on old kernels and either work or fail as
> appropriate, depending on whether the new features they're using must be
> implemented or can be silently ignored.

I see. Thanks for the explanation. Then the expedited flag should
clearly be part of the mandatory flags.

Can you point me to other system calls that are doing this ?

Thanks,

Mathieu

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

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