----- On Jan 5, 2016, at 7:04 AM, Will Deacon will.deacon@xxxxxxx wrote: > 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. Hi Will, This is an excellent question. My initial thinking was that only the thread registering the cache would read it, but now that you ask, there might be use-cases where other threads would be interested in reading each other's current CPU number. For instance, an application could create a linked list or hash map of thread control structures, which could contain the current CPU number of each thread. A dispatch thread could then traverse or lookup this structure to see on which CPU each thread is running and do work queue dispatch or scheduling decisions accordingly. This use-case would imply ensuring that reading the current CPU value from another CPU will never result in reading a garbage value. If we indeed intend to enable this use-case, we should: 1) Add an alignment check on the cpu_cache pointer. Should we return -EINVAL if unaligned ? 2) Document this alignment requirement in the man page, and the atomicity guarantees it provides, The tiny downside of having this alignment requirement is that it would not be possible to put the cpu_cache into a packed structure. I don't think anyone would care though. Thanks! Mathieu > > Cheers, > > Will -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com -- 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
