* Dave Hansen <dave@xxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
