Hi, Michael Sullivan proposed a clever hack abusing mprotect() to perform the same effect as sys_membarrier() I submitted a few years ago ( https://lkml.org/lkml/2010/4/18/15 ).
At that time, the sys_membarrier implementation was deemed technically sound, but there were not enough users of the system call to justify its inclusion. So far, the number of users of liburcu has increased, but liburcu still appears to be the only direct user of sys_membarrier. On this front, we could argue that many other system calls have only one user: glibc. In that respect, liburcu is quite similar to glibc. So the question as it stands appears to be: would you be comfortable having users abuse mprotect(), relying on its side-effect of issuing a smp_mb() on each targeted CPU for the TLB shootdown, as an effective implementation of process-wide memory barrier ? Thoughts ? Thanks! Mathieu ----- Original Message ----- > From: "Michael Sullivan" <[email protected]> > To: "Mathieu Desnoyers" <[email protected]> > Cc: [email protected] > Sent: Thursday, March 12, 2015 12:04:07 PM > Subject: Re: [lttng-dev] Alternative to signals/sys_membarrier() in liburcu > On Thu, Mar 12, 2015 at 10:57 AM, Mathieu Desnoyers < > [email protected] > wrote: > > Even though it depends on internal behavior not currently specified by > > mprotect, > > > I'd very much like to see the prototype you have, > > I ended up posting my code at > https://github.com/msullivan/userspace-rcu/tree/msync-barrier . > The interesting patch is > https://github.com/msullivan/userspace-rcu/commit/04656b468d418efbc5d934ab07954eb8395a7ab0 > . > Quick blog post I wrote about it at > http://www.msully.net/blog/2015/02/24/forcing-memory-barriers-on-other-cpus-with-mprotect2/ > . > (I talked briefly about sys_membarrier in the post as best as I could piece > together from LKML; if my comment on it is inaccurate I can edit the post.) > -Michael Sullivan -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com
_______________________________________________ lttng-dev mailing list [email protected] http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
