----- On Jan 5, 2016, at 12:31 PM, Mathieu Desnoyers mathieu.desnoyers@xxxxxxxxxxxx wrote: > ----- 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, Related question: if we check that cpu_cache pointer is aligned on 4 bytes, does put_user() then guarantee single-copy atomicity on all architectures ? Thanks, Mathieu > > 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 -- 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
