lkml.org 
[lkml]   [2016]   [Jan]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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


\
 
 \ /
  Last update: 2016-01-05 13:41    [W:0.146 / U:0.084 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site