Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1319182
| From | Mathieu Desnoyers <mathieu.desnoyers@efficios.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [RFC PATCH v2 1/3] getcpu_cache system call: cache CPU number of running thread |
| Date | 2016-01-27 18:40 +0100 |
| Message-ID | <qVCeu-72J-27@gated-at.bofh.it> (permalink) |
| References | <qVBBL-6sQ-3@gated-at.bofh.it> <qVBBN-6sQ-27@gated-at.bofh.it> <qVC4P-6X5-45@gated-at.bofh.it> <qVC4P-6X5-43@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
----- On Jan 27, 2016, at 12:24 PM, Thomas Gleixner tglx@linutronix.de wrote: > On Wed, 27 Jan 2016, Josh Triplett wrote: >> With the dynamic allocation removed, this seems sensible to me. One >> minor nit: s/int32_t/uint32_t/g, since a location intended to hold a CPU >> number should never need to hold a negative number. > > You try to block the future of computing: https://lwn.net/Articles/638673/ Besides impossible architectures, there is actually a use-case for signedness here. It makes it possible to initialize the cpu number cache to a negative value, e.g. -1, in userspace. Then, a check for value < 0 can be used to figure out cases where the getcpu_cache system call is not implemented, and where a fallback (vdso or getcpu syscall) needs to be used. This is why I have chosen a signed type for the cpu cache so far. Thoughts ? Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
[RFC PATCH v2 0/3] getcpu_cache system call Mathieu Desnoyers <mathieu.desnoyers@efficios.com> - 2016-01-27 18:00 +0100
[RFC PATCH v2 3/3] getcpu_cache: wire up x86 32/64 system call Mathieu Desnoyers <mathieu.desnoyers@efficios.com> - 2016-01-27 18:00 +0100
[RFC PATCH v2 1/3] getcpu_cache system call: cache CPU number of running thread Mathieu Desnoyers <mathieu.desnoyers@efficios.com> - 2016-01-27 18:00 +0100
Re: [RFC PATCH v2 1/3] getcpu_cache system call: cache CPU number of running thread Thomas Gleixner <tglx@linutronix.de> - 2016-01-27 18:30 +0100
Re: [RFC PATCH v2 1/3] getcpu_cache system call: cache CPU number of running thread Mathieu Desnoyers <mathieu.desnoyers@efficios.com> - 2016-01-27 18:40 +0100
Re: [RFC PATCH v2 1/3] getcpu_cache system call: cache CPU number of running thread Josh Triplett <josh@joshtriplett.org> - 2016-01-27 19:10 +0100
Re: [RFC PATCH v2 1/3] getcpu_cache system call: cache CPU number of running thread Mathieu Desnoyers <mathieu.desnoyers@efficios.com> - 2016-01-27 19:50 +0100
Re: [RFC PATCH v2 1/3] getcpu_cache system call: cache CPU number of running thread Josh Triplett <josh@joshtriplett.org> - 2016-01-27 20:40 +0100
Re: [RFC PATCH v2 1/3] getcpu_cache system call: cache CPU number of running thread Mathieu Desnoyers <mathieu.desnoyers@efficios.com> - 2016-01-27 22:10 +0100
Re: [RFC PATCH v2 1/3] getcpu_cache system call: cache CPU number of running thread Josh Triplett <josh@joshtriplett.org> - 2016-01-27 22:40 +0100
Re: [RFC PATCH v2 1/3] getcpu_cache system call: cache CPU number of running thread Andrew Hunter <ahh@google.com> - 2016-01-27 19:10 +0100
Re: [RFC PATCH v2 1/3] getcpu_cache system call: cache CPU number of running thread Thomas Gleixner <tglx@linutronix.de> - 2016-01-27 18:30 +0100
Re: [RFC PATCH v2 1/3] getcpu_cache system call: cache CPU number of running thread Thomas Gleixner <tglx@linutronix.de> - 2016-01-27 18:40 +0100
Re: [RFC PATCH v2 1/3] getcpu_cache system call: cache CPU number of running thread Mathieu Desnoyers <mathieu.desnoyers@efficios.com> - 2016-01-27 22:40 +0100
Re: [RFC PATCH v2 1/3] getcpu_cache system call: cache CPU number of running thread Thomas Gleixner <tglx@linutronix.de> - 2016-01-27 18:40 +0100
Re: [RFC PATCH v2 1/3] getcpu_cache system call: cache CPU number of running thread Mathieu Desnoyers <mathieu.desnoyers@efficios.com> - 2016-01-27 18:40 +0100
Re: [RFC PATCH v2 1/3] getcpu_cache system call: cache CPU number of running thread Josh Triplett <josh@joshtriplett.org> - 2016-01-27 18:30 +0100
csiph-web