On Thu, 12 Mar 2015 20:56:00 +0000 (UTC) Mathieu Desnoyers <[email protected]> wrote:
> (sorry for re-send, my mail client tricked me into posting HTML > to lkml) > > 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 ? What are you going to do if some future ARM or x86 CPU update with hardware TLB shootdown appears ? All your code will start to fail on new kernels using that property, and in nasty insidious ways. Also doesn't sun4d have hardware shootdown for 16 processors or less ? I would have thought a membarrier was a lot safer and it can be made to do whatever horrible things are needed on different processors (indeed it could even be a pure libc hotpath if some future cpu grows this ability) Alan _______________________________________________ lttng-dev mailing list [email protected] http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
