Messages in this thread | | | Date | Tue, 5 Jan 2016 12:04:01 +0000 | From | Will Deacon <> | Subject | Re: [RFC PATCH 1/3] getcpu_cache system call: cache CPU number of running thread |
| |
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
| |