On Sun, Sep 24 2023 at 00:50, Thomas Gleixner wrote:
> On Tue, Sep 19 2023 at 14:30, Thomas Gleixner wrote:
> That's way better because it describes the scope and the task will
> either schedule out in lock() on contention or provide a sensible lazy
> preemption point in preempt_lazy_enable(). It also nests properly:
>
> preempt_lazy_disable();
> lock(A);
> do_stuff()
> preempt_lazy_disable();
> lock(B);
> do_other_stuff();
> unlock(B);
> preempt_lazy_enable();
> unlock(A);
> preempt_lazy_enable();
>
> So in this case it does not matter wheter do_stuff() is invoked from a
> lock held section or not. The scope which defines the throughput
> relevant hint to the scheduler is correct in any case.
Which also means that automatically injecting it into lock primitives
makes suddenly sense in the same way as the implicit preempt_disable()
in the rw/spinlock primitives does.
Thanks,
tglx
