public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Aaron Lu <ziqianlu@bytedance.com>
To: K Prateek Nayak <kprateek.nayak@amd.com>
Cc: Benjamin Segall <bsegall@google.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Valentin Schneider <vschneid@redhat.com>,
	Chengming Zhou <chengming.zhou@linux.dev>,
	Josh Don <joshdon@google.com>, Ingo Molnar <mingo@redhat.com>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Xi Wang <xii@google.com>,
	linux-kernel@vger.kernel.org, Juri Lelli <juri.lelli@redhat.com>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Mel Gorman <mgorman@suse.de>,
	Chuyi Zhou <zhouchuyi@bytedance.com>,
	Jan Kiszka <jan.kiszka@siemens.com>,
	Florian Bezdeka <florian.bezdeka@siemens.com>,
	Songtang Liu <liusongtang@bytedance.com>,
	Chen Yu <yu.c.chen@intel.com>,
	Matteo Martelli <matteo.martelli@codethink.co.uk>,
	Michal Koutn?? <mkoutny@suse.com>,
	Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Subject: Re: [PATCH v4 3/5] sched/fair: Switch to task based throttle model
Date: Wed, 10 Sep 2025 11:03:29 +0800	[thread overview]
Message-ID: <20250910030329.GB90@bytedance> (raw)
In-Reply-To: <20250904110504.GG42@bytedance>

On Thu, Sep 04, 2025 at 07:05:04PM +0800, Aaron Lu wrote:
> On Thu, Sep 04, 2025 at 03:21:06PM +0530, K Prateek Nayak wrote:
> > Hello Aaron,
> > 
> > On 9/4/2025 1:46 PM, Aaron Lu wrote:
> > > @@ -8722,15 +8730,6 @@ static void check_preempt_wakeup_fair(struct rq *rq, struct task_struct *p, int
> > >  	if (unlikely(se == pse))
> > >  		return;
> > >  
> > > -	/*
> > > -	 * This is possible from callers such as attach_tasks(), in which we
> > > -	 * unconditionally wakeup_preempt() after an enqueue (which may have
> > > -	 * lead to a throttle).  This both saves work and prevents false
> > > -	 * next-buddy nomination below.
> > > -	 */
> > > -	if (unlikely(throttled_hierarchy(cfs_rq_of(pse))))
> > > -		return;
> > 
> > I think we should have a:
> > 
> > 	if (task_is_throttled(p))
> > 		return;
> > 
> > here. I can see at least one possibility via prio_changed_fair()
> 
> Ah right. I didn't realize wakeup_preempt() can be called for a throttled
> task, I think it is not expected. What about forbid that :)
> (not tested in anyway, just to show the idea and get feedback)
>

Turned out there are other places that also call wakeup_preempt() for a
throttled task, like sched_setaffinity() -> move_queued_task() ->
wakeup_preempt(), and it's not possible to change the logic there as
it's outside of fair, so I'll go with your suggestion to add a
task_is_throttled() check in check_preempt_wakeup_fair().

> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index cb93e74a850e8..f1383aede764f 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -13135,7 +13135,11 @@ static void task_fork_fair(struct task_struct *p)
>  static void
>  prio_changed_fair(struct rq *rq, struct task_struct *p, int oldprio)
>  {
> -	if (!task_on_rq_queued(p))
> +	/*
> +	 * p->on_rq can be set for throttled task but there is no need to
> +	 * check wakeup preempt for throttled task, so use p->se.on_rq instead.
> +	 */
> +	if (!p->se.on_rq)
>  		return;
>  
>  	if (rq->cfs.nr_queued == 1)
> 
> > where a throttled task might reach here. Rest looks good. I'll
> > still wait on Ben for the update_cfs_group() bits :)
> > 
> > > -
> > >  	if (sched_feat(NEXT_BUDDY) && !(wake_flags & WF_FORK) && !pse->sched_delayed) {
> > >  		set_next_buddy(pse);
> > >  	}

  parent reply	other threads:[~2025-09-10  3:03 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-29  8:11 [PATCH v4 0/5] Defer throttle when task exits to user Aaron Lu
2025-08-29  8:11 ` [PATCH v4 1/5] sched/fair: Add related data structure for task based throttle Aaron Lu
2025-09-03  8:05   ` [tip: sched/core] " tip-bot2 for Valentin Schneider
2025-08-29  8:11 ` [PATCH v4 2/5] sched/fair: Implement throttle task work and related helpers Aaron Lu
2025-09-03  8:05   ` [tip: sched/core] " tip-bot2 for Valentin Schneider
2025-08-29  8:11 ` [PATCH v4 3/5] sched/fair: Switch to task based throttle model Aaron Lu
2025-09-03  8:05   ` [tip: sched/core] " tip-bot2 for Valentin Schneider
2025-09-03 14:51   ` [PATCH v4 3/5] " Peter Zijlstra
2025-09-03 17:12     ` K Prateek Nayak
2025-09-03 20:27       ` Peter Zijlstra
2025-09-04  5:44         ` K Prateek Nayak
2025-09-04  7:04           ` Aaron Lu
2025-09-05 11:37             ` Aaron Lu
2025-09-05 12:53               ` Peter Zijlstra
2025-09-08 11:05                 ` [PATCH] sched/fair: Propagate load for throttled cfs_rq Aaron Lu
2025-09-09  4:20                   ` kernel test robot
2025-09-09  6:17                     ` Aaron Lu
2025-09-09  6:22                       ` K Prateek Nayak
2025-09-09  6:27                         ` Aaron Lu
2025-09-10  9:55                           ` Aaron Lu
2025-09-03 20:46       ` [PATCH v4 3/5] sched/fair: Switch to task based throttle model Benjamin Segall
2025-09-04  6:03         ` K Prateek Nayak
2025-09-09  4:10           ` Benjamin Segall
2025-09-04  8:16         ` Aaron Lu
2025-09-04  9:51           ` K Prateek Nayak
2025-09-04 11:05             ` Aaron Lu
2025-09-04 14:20               ` K Prateek Nayak
2025-09-09  3:58               ` Benjamin Segall
2025-09-09 12:03                 ` Aaron Lu
2025-09-10  3:03               ` Aaron Lu [this message]
2025-09-04 12:04           ` Aaron Lu
2025-09-05  7:53             ` Aaron Lu
2025-09-03 20:55   ` Benjamin Segall
2025-09-04 11:26     ` Aaron Lu
2025-09-04 11:30       ` Aaron Lu
2025-08-29  8:11 ` [PATCH v4 4/5] sched/fair: Task based throttle time accounting Aaron Lu
2025-09-03  8:05   ` [tip: sched/core] " tip-bot2 for Aaron Lu
2025-08-29  8:11 ` [PATCH v4 5/5] sched/fair: Get rid of throttled_lb_pair() Aaron Lu
2025-09-03  8:05   ` [tip: sched/core] " tip-bot2 for Aaron Lu
2025-09-01 10:03 ` [PATCH v4 0/5] Defer throttle when task exits to user Peter Zijlstra
2025-12-02  8:59 ` Bezdeka, Florian
2025-12-02  9:43   ` Aaron Lu
2025-12-02 10:09     ` Florian Bezdeka
2025-12-02 12:01       ` Aaron Lu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20250910030329.GB90@bytedance \
    --to=ziqianlu@bytedance.com \
    --cc=bigeasy@linutronix.de \
    --cc=bsegall@google.com \
    --cc=chengming.zhou@linux.dev \
    --cc=dietmar.eggemann@arm.com \
    --cc=florian.bezdeka@siemens.com \
    --cc=jan.kiszka@siemens.com \
    --cc=joshdon@google.com \
    --cc=juri.lelli@redhat.com \
    --cc=kprateek.nayak@amd.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=liusongtang@bytedance.com \
    --cc=matteo.martelli@codethink.co.uk \
    --cc=mgorman@suse.de \
    --cc=mingo@redhat.com \
    --cc=mkoutny@suse.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=vincent.guittot@linaro.org \
    --cc=vschneid@redhat.com \
    --cc=xii@google.com \
    --cc=yu.c.chen@intel.com \
    --cc=zhouchuyi@bytedance.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox