On Mon, Oct 07, 2019 at 06:56:11PM +0200, Uladzislau Rezki wrote: > On Mon, Oct 07, 2019 at 06:34:43PM +0200, Daniel Wagner wrote: > > I supppose, one thing which would help in this discussion, is what do > > you gain by using preempt_disable() instead of moving the lock up? > > Do you have performance numbers which could justify the code? > > > Actually there is a high lock contention on vmap_area_lock, because it > is still global. You can have a look at last slide: > > https://linuxplumbersconf.org/event/4/contributions/547/attachments/287/479/Reworking_of_KVA_allocator_in_Linux_kernel.pdf > > so this change will make it a bit higher. Thanks! I suspected something like this :( On the todo-list page you stating that vmap_area_lock could be splitted and therefore reduce the contention. If you could avoid those preempt_disable() tricks and just use plain spin_locks() to protect it would be really helpful. > From the other hand i agree > that for rt it should be fixed, probably it could be done like: > > ifdef PREEMPT_RT > migrate_disable() > #else > preempt_disable() > ... > > but i am not sure it is good either. I don't think this way to go. I guess Sebastian and Thomas have a better idea how to address this for PREEMPT_RT.
