<html><body><div style="font-family: times new roman, new york, times, serif; font-size: 12pt; color: #000000"><div><br></div><hr id="zwchr"><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;" data-mce-style="border-left: 2px solid #1010FF; margin-left: 5px; padding-left: 5px; color: #000; font-weight: normal; font-style: normal; text-decoration: none; font-family: Helvetica,Arial,sans-serif; font-size: 12pt;"><b>From: </b>"Michael Sullivan" <sully@msully.net><br><b>To: </b>lttng-dev@lists.lttng.org<br><b>Sent: </b>Tuesday, February 10, 2015 7:03:53 PM<br><b>Subject: </b>[lttng-dev] Alternative to signals/sys_membarrier() in liburcu<br><div><br></div><div dir="ltr"><div><div><div><div><div>I've been looking at the RCU library (as part of gathering examples for my research on weak memory models) and was thinking about ways to force other threads to issue barriers. Since it seems like sys_membarrier() never made it into the kernel, I was pondering whether there was some other way to more or less get its effect; as it turns out, there is, but it is a hack: mprotect(2).<br><div><br></div></div>When a thread revokes write permissions on a page, the kernel needs to do a TLB shootdown to make sure that none of the other CPUs running code in that address space have a writable mapping for that page cached. In Linux, this is done by forcing code to invalidate the mappings to run on every CPU in the address space, and waiting for completion. The code for the "run this function on another CPU" mechanism forces the target CPU to issue an smp_mb().<br><div><br></div></div>(In practice TLB shootdowns are done when permissions are added, not just when they are removed, but they needn't be; faults caused by using a cached entry with less permissions can be fixed up by the page fault handler. They're also needed when unmapping memory, but mprotect() seems cheaper than having to mmap() and munmap(). Also TLB shootdowns aren't needed if the page is non-present because it's never been backed or has been swapped out, so mlock(2) is used to keep it in place).<br><div><br></div></div>I hacked this up and in my limited testing, it does seem to have way better write side performance than the signal version has. That said, it is also super hacky and is certainly depending on behaviors of mprotect() that are not actually specified. It would be unusual, I think, to implement mprotect() in a way where this didn't work? It may well be to janky to actually be useful, though.<br><div><br></div></div>I can send the code if you're interested.</div></div></blockquote><div><br></div><div>That's certainly an interesting way to mimick sys_membarrier!<br></div><div><br></div><div>Even though it depends on internal behavior not currently specified by mprotect,<br></div><div>I'd very much like to see the prototype you have,<br></div><div><br></div><div>Thanks!<br></div><div><br></div><div>Mathieu<br></div><div><br></div><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;" data-mce-style="border-left: 2px solid #1010FF; margin-left: 5px; padding-left: 5px; color: #000; font-weight: normal; font-style: normal; text-decoration: none; font-family: Helvetica,Arial,sans-serif; font-size: 12pt;"><div dir="ltr"><div><div><br></div></div>-Michael Sullivan<br></div><br>_______________________________________________<br>lttng-dev mailing list<br>lttng-dev@lists.lttng.org<br>http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev<br></blockquote><div><br><br></div><div><br></div><div>-- <br></div><div><span name="x"></span>Mathieu Desnoyers<br>EfficiOS Inc.<br>http://www.efficios.com<span name="x"></span><br></div></div></body></html>