# Re: \[RFC PATCH\] getcpu\_cache system call: caching current CPU number (x86)

- From: Mathieu Desnoyers \<hidden\>
- Date: 2015-07-13 16:07:21 
- List: linux-api
- Page: https://ratatoskr.run/linux-api/2015/07/13329227
- Thread: https://ratatoskr.run/linux-api/2015/07/13329227/t.md

```text
----- On Jul 13, 2015, at 11:30 AM, Andrew Hunter ahh-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org wrote:

> On Mon, Jul 13, 2015 at 8:27 AM, Mathieu Desnoyers
> [ref] wrote:
>> percpu segments will likely not solve everything. I have a use-case
>> with dynamically allocated per-cpu ring buffer in user-space (lttng-ust)
>> which can be a challenge for percpu segments. Having a fast getcpu()
>> is a win in those cases.
>>
> 
> Note that percpu segments allow userspace to trivially implement fast getcpu.
> 
> For the record, Paul and I currently think the best solution is percpu
> segments + some variant of a restart-sequence API (we'll have a patch
> soon.)

Although useful in many situations, percpu segments still have some
limitations AFAIU:

- They are not available on all architectures (very x86-specific),
- Some user-space applications already use those segments.

So as long as we only target user-space code that does not use GS,
and which runs on x86, the percpu segments seems to be a good idea.
However, implementing a more general approach for a fast getcpu cache
still appears somewhat useful for the general case.

Thanks,

Mathieu

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
```