[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANRm+CzOPieLG6bg=2XJ3jkEw268ua4DFZyubL5jT6Pu7nfk7A@mail.gmail.com>
Date: Thu, 13 Nov 2025 21:36:48 +0800
From: Wanpeng Li <kernellwp@...il.com>
To: K Prateek Nayak <kprateek.nayak@....com>
Cc: Peter Zijlstra <peterz@...radead.org>, Ingo Molnar <mingo@...hat.com>,
Thomas Gleixner <tglx@...utronix.de>, Paolo Bonzini <pbonzini@...hat.com>,
Sean Christopherson <seanjc@...gle.com>, Steven Rostedt <rostedt@...dmis.org>,
Vincent Guittot <vincent.guittot@...aro.org>, Juri Lelli <juri.lelli@...hat.com>,
linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
Wanpeng Li <wanpengli@...cent.com>
Subject: Re: [PATCH 02/10] sched/fair: Add rate-limiting and validation helpers
Hi Prateekļ¼
On Wed, 12 Nov 2025 at 14:44, K Prateek Nayak <kprateek.nayak@....com> wrote:
>
> On 11/12/2025 12:10 PM, K Prateek Nayak wrote:
> >> + if (task_rq(p_yielding) != rq || task_rq(p_target) != rq)
> >
> > yield_to() has already checked for this under double_rq_lock()
> > so this too should be unnecessary.
>
> nvm! We only check if the task_rq(p_target) is stable under the
> rq_lock or not. Just checking "task_rq(p_target) != rq" should
> be sufficient here.
You're right! Since yield_to() passes rq = this_rq() , the yielding
task is guaranteed on rq . But p_target may be on a different CPU
(yield_to supports cross-CPU). Our deboost only works for same-rq
tasks, so checking only task_rq(p_target) != rq is sufficient. I'll
remove the redundant task_rq(p_yielding) != rq check. Thanks!
Regards,
Wanpeng
Powered by blists - more mailing lists