* Dave Hansen <d...@sr71.net> wrote:
> > Applications that frequently get called will get hammed into the ground
> > with
> > serialisation on mmap_sem not to mention the cost of the syscall entry/exit.
>
> I think we can do both of them without mmap_sem, as long as we resign
> ourselves
> to this just being fundamentally racy (which it is already, I think). But,
> is
> it worth performance-tuning things that we don't expect performance-sensitive
> apps to be using in the first place? They'll just use the RDPKRU/WRPKRU
> instructions directly.
>
> Ingo, do you still feel strongly that these syscalls (pkey_set/get()) should
> be
> included? Of the 5, they're definitely the two with the weakest
> justification.
Firstly, I'd like to thank Mel for the review, having this kind of high level
interface discussion was exactly what I was hoping for before we merged any ABI
patches.
So my hope was that we'd also grow some debugging features: such as a periodic
watchdog timer clearing all non-allocated pkeys of a task and re-setting them
to
their (kernel-)known values and thus forcing user-space to coordinate key
allocation/freeing.
While allocation/freeing of keys is very likely a slow path in any reasonable
workload, _setting_ the values of pkeys could easily be a fast path. The whole
point of pkeys is to allow both thread local and dynamic mapping and unmapping
of
memory ranges, without having to touch any page table attributes in the hot
path.
Now another, more fundamental question is that pkeys are per-CPU (per thread)
on
the hardware side - so why do we even care about the mmap_sem in the syscalls
in
the first place? If we want any serialization wouldn't a pair of
get_cpu()/put_cpu() preemption control calls be enough? Those would also be
much
cheaper.
The idea behind my suggestion to manage all pkey details via a kernel interface
and 'shadow' the pkeys state in the kernel was that if we don't even offer a
complete system call interface then user-space is _forced_ into using the raw
instructions and into implementing a (potentially crappy) uncoordinated API or
not
implementing any API at all but randomly using fixed pkey indices.
My hope was to avoid that, especially since currently _all_ memory mapping
details
on x86 are controlled via system calls. If we don't offer that kind of facility
then we force user-space into using the raw instructions and will likely end up
with a poor user-space interface.
So the question is, what is user-space going to do? Do any glibc patches exist?
How are the user-space library side APIs going to look like?
Thanks,
Ingo
