Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.34 as permitted sender) client-ip=23.128.96.34;
From:   Thomas Gleixner <tglx@linutronix.de>
To:     Linus Torvalds <torvalds@linux-foundation.org>
Cc:     Peter Zijlstra <peterz@infradead.org>,
        Ankur Arora <ankur.a.arora@oracle.com>,
        linux-kernel@vger.kernel.org, linux-mm@kvack.org, x86@kernel.org,
        akpm@linux-foundation.org, luto@kernel.org, bp@alien8.de,
        dave.hansen@linux.intel.com, hpa@zytor.com, mingo@redhat.com,
        juri.lelli@redhat.com, vincent.guittot@linaro.org,
        willy@infradead.org, mgorman@suse.de, rostedt@goodmis.org,
        jon.grimm@amd.com, bharata@amd.com, raghavendra.kt@amd.com,
        boris.ostrovsky@oracle.com, konrad.wilk@oracle.com,
        jgross@suse.com, andrew.cooper3@citrix.com
Subject: Re: [PATCH v2 7/9] sched: define TIF_ALLOW_RESCHED
In-Reply-To: <87h6nkh5bw.ffs@tglx>
References: <20230830184958.2333078-8-ankur.a.arora@oracle.com>
 <20230908070258.GA19320@noisy.programming.kicks-ass.net>
 <87zg1v3xxh.fsf@oracle.com>
 <CAHk-=whagwHrDxhjUVrRPhq78YC195KrSGzuC722-4MvAz40pw@mail.gmail.com>
 <87edj64rj1.fsf@oracle.com>
 <CAHk-=wi0bXpgULVVLc2AdJcta-fvQP7yyFQ_JtaoHUiPrqf--A@mail.gmail.com>
 <87zg1u1h5t.fsf@oracle.com>
 <CAHk-=whMkp68vNxVn1H3qe_P7n=X2sWPL9kvW22dsvMFH8FcQQ@mail.gmail.com>
 <20230911150410.GC9098@noisy.programming.kicks-ass.net>
 <87h6o01w1a.fsf@oracle.com>
 <20230912082606.GB35261@noisy.programming.kicks-ass.net>
 <87cyyfxd4k.ffs@tglx>
 <CAHk-=whnwC01m_1f-gaM1xbvvwzwTiKitrWniA-ChZv+bM03dg@mail.gmail.com>
 <87led2wdj0.ffs@tglx> <87h6nkh5bw.ffs@tglx>
Date:   Sun, 24 Sep 2023 02:10:12 +0200
Message-ID: <87bkdsh1nf.ffs@tglx>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: bulk

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