On 9/19/23 06:42, Matteo Rizzo wrote: > On Mon, 18 Sept 2023 at 19:39, Ingo Molnar <mingo@xxxxxxxxxx> wrote: >> What's the split of the increase in overhead due to SLAB_VIRTUAL=y, between >> user-space execution and kernel-space execution? >> > Same benchmark as before (compiling a kernel on a system running the patched > kernel): Thanks for running those. One more situation that comes to mind is how this will act under memory pressure. Will some memory pressure make contention on 'slub_kworker_lock' visible or make the global TLB flushes less bearable? In any case, none of this looks _catastrophic_. It's surely a cost that some folks will pay. But I really do think it needs to be more dynamic. There are a _couple_ of reasons for this. If it's only a compile-time option, it's never going to get turned on except for maybe ChromeOS and the datacenter folks that are paranoid. I suspect the distros will never turn it on. A lot of questions get easier if you can disable/enable it at runtime. For instance, what do you do if the virtual area fills up? You _could_ just go back to handing out direct map addresses. Less secure? Yep. But better than crashing (for some folks). It also opens up the door to do this per-slab. That alone would be a handy debugging option.
