Hello Christophe, thanks for the feedback! On Thu, 2020-02-06 at 07:23 +0100, Christophe Leroy wrote: > > Due to not locking nor using atomic variables, the impact on the > > lockless pagetable walk is intended to be minimum. > > atomic variables have a lot less impact than preempt_enable/disable. > > preemt_disable forces a re-scheduling, it really has impact. Why not use > atomic variables instead ? In fact, v5 of this patch used atomic variables. But it seems to cause contention on a single exclusive cacheline, which had no better performance than locking. (discussion here: http://patchwork.ozlabs.org/patch/1171012/) When I try to understand the effect of preempt_disable(), all I can see is a barrier() and possibly a preempt_count_inc(), which updates a member of current thread struct if CONFIG_PREEMPT_COUNT is enabled. If CONFIG_PREEMPTION is also enabled, preempt_enable() can run a __preempt_schedule() on unlikely(__preempt_count_dec_and_test()). On most configs available, CONFIG_PREEMPTION is not set, being replaced either by CONFIG_PREEMPT_NONE (kernel defconfigs) or CONFIG_PREEMPT_VOLUNTARY in most supported distros. With that, most probably CONFIG_PREEMPT_COUNT will also not be set, and preempt_{en,dis}able() are replaced by a barrier(). Using preempt_disable approach, I intent to get better performance for most used cases. What do you think of it? I am still new on this subject, and I am still trying to better understand how it works. If you notice something I am missing, please let me know. Best regards, Leonardo Bras
Attachment:
signature.asc
Description: This is a digitally signed message part
