Re: [RFC PATCH] percpu system call: fast userspace percpu critical sections

[Andy Lutomirski]

On Tue, May 26, 2015 at 2:20 PM, Andi Kleen <andi@xxxxxxxxxxxxxx> wrote:
>
> I haven't thought too much about it, but doing it in a vdso seems
> reasonable. It would mean that the scheduler hot path would
> need to know about its address though.
>
>> > You appear to summarize the two things that are added to the kernel with
>> > this RFC patch:
>> > - faster getcpu(): 12.7 ns -> 0.3 ns
>>
>> Yeah, I figured that out the second time I read your email and re-read
>> the original message, but I apparently forgot to fix up the email I
>> was typing.
>
> The high speed users seem to have all switched to using LSL directly,
> which is even faster. Since there are already users it cannot be changed
> anymore. Should probably just document this as an official ABI,
> and provide some standard include file with inline code.
>
>> IIRC some other OS's use gs as a userspace per-cpu pointer instead of
>> a per-thread pointer.  Would we want to consider enabling that?
>> This may interact oddly with the WIP wrgsbase stuff.  (Grr, Intel, why
>> couldn't you have made wrgsbase reset the gs selector to zero?  That
>> would have been so much nicer.)
>
> Applications really want the extra address registers. For example
> OpenJDK could free a GPR. And it's needed for the TLS of user space
> threads, which are becoming more and more popular. So there are
> already more important users queued.

This isn't necessarily the end of the world.  They could turn it off
or hopefully repurpose or extend their FS usage instead of requiring
GS.

IOW, I think that ARCH_SET_GS should continue working, as should
wrgsbase.  We could allow a program, strictly as an alternative, to do
ARCH_SET_GS_PERCPU or something.  (If we do that, we should wire up
arch_prctl for x86_32 as well.  We could further consider restricting
the new per-cpu mode to require a specific *nonzero* value for the
selector.  Also, it's really annoying that we'll be forced to assign
some meaning to a non-zero selector with unexpected gsbase during
context switch.)

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/