Hi Mathieu, On Tue, Jan 05, 2016 at 02:01:58AM -0500, Mathieu Desnoyers wrote: > Expose a new system call allowing threads to register userspace memory > areas where to store the CPU number on which the calling thread is > running. Scheduler migration sets the TIF_NOTIFY_RESUME flag on the > current thread. Upon return to user-space, a notify-resume handler > updates the current CPU value within each registered user-space memory > area. User-space can then read the current CPU number directly from > memory. What guarantees do you provide if a thread other than the one which registered the cache tries to access the value? Obviously, there's a potential data race here with the kernel issuing a parallel update, but are you intending to have single-copy atomicity semantics (like relaxed atomics in C11) or is this simply going to give you junk? I ask because, in the absence of alignment checks on the cache pointer, we can't guarantee single-copy atomicity on ARM when the kernel writes the current CPU value. Cheers, Will -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
