Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1301473
| From | Will Deacon <will.deacon@arm.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [RFC PATCH 1/3] getcpu_cache system call: cache CPU number of running thread |
| Date | 2016-01-05 13:10 +0100 |
| Message-ID | <qNyB5-2yO-27@gated-at.bofh.it> (permalink) |
| References | <qNtUK-6Zq-7@gated-at.bofh.it> <qNtUK-6Zq-11@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
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-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
[RFC PATCH 1/3] getcpu_cache system call: cache CPU number of running thread Mathieu Desnoyers <mathieu.desnoyers@efficios.com> - 2016-01-05 08:10 +0100
Re: [RFC PATCH 1/3] getcpu_cache system call: cache CPU number of running thread Will Deacon <will.deacon@arm.com> - 2016-01-05 13:10 +0100
Re: [RFC PATCH 1/3] getcpu_cache system call: cache CPU number of running thread Mathieu Desnoyers <mathieu.desnoyers@efficios.com> - 2016-01-05 18:40 +0100
Re: [RFC PATCH 1/3] getcpu_cache system call: cache CPU number of running thread Mathieu Desnoyers <mathieu.desnoyers@efficios.com> - 2016-01-05 18:40 +0100
Re: [RFC PATCH 1/3] getcpu_cache system call: cache CPU number of running thread Russell King - ARM Linux <linux@arm.linux.org.uk> - 2016-01-05 18:50 +0100
Re: [RFC PATCH 1/3] getcpu_cache system call: cache CPU number of running thread Mathieu Desnoyers <mathieu.desnoyers@efficios.com> - 2016-01-05 18:50 +0100
Re: [RFC PATCH 1/3] getcpu_cache system call: cache CPU number of running thread "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2016-01-05 22:50 +0100
Re: [RFC PATCH 1/3] getcpu_cache system call: cache CPU number of running thread Mathieu Desnoyers <mathieu.desnoyers@efficios.com> - 2016-01-05 23:40 +0100
Re: [RFC PATCH 1/3] getcpu_cache system call: cache CPU number of running thread "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2016-01-06 00:00 +0100
csiph-web