On Fri, 15 Dec 2017, Mathieu Desnoyers wrote:
> Another aspect that worries me is applications using the gs segment selector
> for other purposes. Suddenly reserving the gs segment selector for use by a
> library like glibc may lead to incompatibilities with applications already
> using it.
On Fri, 15 Dec 2017, Mathieu Desnoyers wrote:
> Another aspect that worries me is applications using the gs segment selector
> for other purposes. Suddenly reserving the gs segment selector for use by a
> library like glibc may lead to incompatibilities with applications already
> using it.
- On Dec 15, 2017, at 10:05 AM, Chris Lameter c...@linux.com wrote:
> On Thu, 14 Dec 2017, Peter Zijlstra wrote:
>
>> > But my company has extensive user space code that maintains a lot of
>> > counters and does other tricks to get full performance out of the
>> > hardware. Such a mechanism
- On Dec 15, 2017, at 10:05 AM, Chris Lameter c...@linux.com wrote:
> On Thu, 14 Dec 2017, Peter Zijlstra wrote:
>
>> > But my company has extensive user space code that maintains a lot of
>> > counters and does other tricks to get full performance out of the
>> > hardware. Such a mechanism
On Thu, 14 Dec 2017, Peter Zijlstra wrote:
> > But my company has extensive user space code that maintains a lot of
> > counters and does other tricks to get full performance out of the
> > hardware. Such a mechanism would also be good from user space. Why keep
> > the good stuff only inside the
On Thu, 14 Dec 2017, Peter Zijlstra wrote:
> > But my company has extensive user space code that maintains a lot of
> > counters and does other tricks to get full performance out of the
> > hardware. Such a mechanism would also be good from user space. Why keep
> > the good stuff only inside the
On Thu, Dec 14, 2017 at 03:14:00PM -0600, Christopher Lameter wrote:
> On Thu, 14 Dec 2017, Mathieu Desnoyers wrote:
>
> > If we port this concept to kernel-space (as I start to understand
> > would be your wish), then a simple pointer store to the current
> > task_struct would suffice.
>
>
On Thu, Dec 14, 2017 at 03:14:00PM -0600, Christopher Lameter wrote:
> On Thu, 14 Dec 2017, Mathieu Desnoyers wrote:
>
> > If we port this concept to kernel-space (as I start to understand
> > would be your wish), then a simple pointer store to the current
> > task_struct would suffice.
>
>
On Thu, 14 Dec 2017, Mathieu Desnoyers wrote:
> If we port this concept to kernel-space (as I start to understand
> would be your wish), then a simple pointer store to the current
> task_struct would suffice.
Certainly such a port would be beneficial for non x86 archs.
But my company has
On Thu, 14 Dec 2017, Mathieu Desnoyers wrote:
> If we port this concept to kernel-space (as I start to understand
> would be your wish), then a simple pointer store to the current
> task_struct would suffice.
Certainly such a port would be beneficial for non x86 archs.
But my company has
On Thu, Dec 14, 2017 at 07:57:08PM +, Mathieu Desnoyers wrote:
> - On Dec 14, 2017, at 2:48 PM, Peter Zijlstra pet...@infradead.org wrote:
>
> > On Thu, Dec 14, 2017 at 12:50:13PM -0600, Christopher Lameter wrote:
> >> Ultimately I wish fast increments like done by this_cpu_inc() could be
On Thu, Dec 14, 2017 at 07:57:08PM +, Mathieu Desnoyers wrote:
> - On Dec 14, 2017, at 2:48 PM, Peter Zijlstra pet...@infradead.org wrote:
>
> > On Thu, Dec 14, 2017 at 12:50:13PM -0600, Christopher Lameter wrote:
> >> Ultimately I wish fast increments like done by this_cpu_inc() could be
- On Dec 14, 2017, at 2:48 PM, Peter Zijlstra pet...@infradead.org wrote:
> On Thu, Dec 14, 2017 at 12:50:13PM -0600, Christopher Lameter wrote:
>> Ultimately I wish fast increments like done by this_cpu_inc() could be
>> implemented in an efficient way on non x86 platforms that do not have
- On Dec 14, 2017, at 2:48 PM, Peter Zijlstra pet...@infradead.org wrote:
> On Thu, Dec 14, 2017 at 12:50:13PM -0600, Christopher Lameter wrote:
>> Ultimately I wish fast increments like done by this_cpu_inc() could be
>> implemented in an efficient way on non x86 platforms that do not have
On Thu, Dec 14, 2017 at 12:50:13PM -0600, Christopher Lameter wrote:
> Ultimately I wish fast increments like done by this_cpu_inc() could be
> implemented in an efficient way on non x86 platforms that do not have
> cheap instructions like that.
So the problem isn't migration; for that we could
On Thu, Dec 14, 2017 at 12:50:13PM -0600, Christopher Lameter wrote:
> Ultimately I wish fast increments like done by this_cpu_inc() could be
> implemented in an efficient way on non x86 platforms that do not have
> cheap instructions like that.
So the problem isn't migration; for that we could
- On Dec 14, 2017, at 1:50 PM, Chris Lameter c...@linux.com wrote:
> On Thu, 14 Dec 2017, Mathieu Desnoyers wrote:
>
>> > I think the proper way to think about gs and fs on x86 is as base
>> > registers. They are essentially values in registers added to the address
>> > generated in an
- On Dec 14, 2017, at 1:50 PM, Chris Lameter c...@linux.com wrote:
> On Thu, 14 Dec 2017, Mathieu Desnoyers wrote:
>
>> > I think the proper way to think about gs and fs on x86 is as base
>> > registers. They are essentially values in registers added to the address
>> > generated in an
On Thu, 14 Dec 2017, Mathieu Desnoyers wrote:
> > I think the proper way to think about gs and fs on x86 is as base
> > registers. They are essentially values in registers added to the address
> > generated in an instruction. As such the approach is transferable to other
> > processor
On Thu, 14 Dec 2017, Mathieu Desnoyers wrote:
> > I think the proper way to think about gs and fs on x86 is as base
> > registers. They are essentially values in registers added to the address
> > generated in an instruction. As such the approach is transferable to other
> > processor
- On Dec 14, 2017, at 11:44 AM, Chris Lameter c...@linux.com wrote:
> On Thu, 14 Dec 2017, Mathieu Desnoyers wrote:
>
>> On x86, yet another possible approach would be to use the gs segment
>> selector to point to user-space per-cpu data. This approach performs
>> similarly to the cpu id
- On Dec 14, 2017, at 11:44 AM, Chris Lameter c...@linux.com wrote:
> On Thu, 14 Dec 2017, Mathieu Desnoyers wrote:
>
>> On x86, yet another possible approach would be to use the gs segment
>> selector to point to user-space per-cpu data. This approach performs
>> similarly to the cpu id
On Thu, 14 Dec 2017, Mathieu Desnoyers wrote:
> On x86, yet another possible approach would be to use the gs segment
> selector to point to user-space per-cpu data. This approach performs
> similarly to the cpu id cache, but it has two disadvantages: it is
> not portable, and it is incompatible
On Thu, 14 Dec 2017, Mathieu Desnoyers wrote:
> On x86, yet another possible approach would be to use the gs segment
> selector to point to user-space per-cpu data. This approach performs
> similarly to the cpu id cache, but it has two disadvantages: it is
> not portable, and it is incompatible
Expose a new system call allowing each thread to register one userspace
memory area to be used as an ABI between kernel and user-space for two
purposes: user-space restartable sequences and quick access to read the
current CPU number value from user-space.
* Restartable sequences (per-cpu
Expose a new system call allowing each thread to register one userspace
memory area to be used as an ABI between kernel and user-space for two
purposes: user-space restartable sequences and quick access to read the
current CPU number value from user-space.
* Restartable sequences (per-cpu
26 matches
Mail list logo
