public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Dengjun Su <dengjun.su@mediatek.com>
Cc: linux-kernel@vger.kernel.org, mike.zhang@mediatek.com,
	haiqiang.gong@mediatek.com, peijun.huang@mediatek.com,
	Ingo Molnar <mingo@redhat.com>,
	Juri Lelli <juri.lelli@redhat.com>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>,
	Valentin Schneider <vschneid@redhat.com>,
	Matthias Brugger <matthias.bgg@gmail.com>,
	AngeloGioacchino Del Regno
	<angelogioacchino.delregno@collabora.com>,
	linux-arm-kernel@lists.infradead.org,
	linux-mediatek@lists.infradead.org
Subject: Re: [PATCH] sched/rt: fix incorrect schedstats for rt thread
Date: Thu, 8 Jan 2026 12:16:32 +0100	[thread overview]
Message-ID: <20260108111632.GH272712@noisy.programming.kicks-ass.net> (raw)
In-Reply-To: <20260108031309.2754003-1-dengjun.su@mediatek.com>

On Thu, Jan 08, 2026 at 11:13:07AM +0800, Dengjun Su wrote:
> For RT thread, only 'set_next_task_rt' will call
> 'update_stats_wait_end_rt' to update schedstats information.
> However, during the RT migration process,
> 'update_stats_wait_start_rt' will be called twice, which
> will cause the values of wait_max and wait_sum to be incorrect.

Right, that looses time. Also note that I think dl has the same issue.

> The specific output as follows:
> $ cat /proc/6046/task/6046/sched | grep wait
> wait_start                                   :             0.000000
> wait_max                                     :        496717.080029
> wait_sum                                     :       7921540.776553
> 
> Add 'update_stats_wait_end_rt' in 'update_stats_dequeue_rt' to
> update schedstats information when dequeue_task.

This needs a few more words on why this is correct -- notably it took me
a little time to find the 'task_on_rq_migrating()' case in
__update_stats_wait_end() which makes this not actually 'end'.

But then the corresponding clause in __update_stats_wait_start() gives
me a headache:

 'wait_start > prev_wait_start'

I mean, wtf. Should that not equally be using task_on_rq_migrating() ?

Can you please take a hard look at all that and fix up things all-round?



  reply	other threads:[~2026-01-08 11:16 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-08  3:13 [PATCH] sched/rt: fix incorrect schedstats for rt thread Dengjun Su
2026-01-08 11:16 ` Peter Zijlstra [this message]
2026-01-09  7:24   ` Dengjun Su
2026-01-12 16:38     ` Peter Zijlstra
2026-01-14 11:55       ` Dengjun Su

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=20260108111632.GH272712@noisy.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=angelogioacchino.delregno@collabora.com \
    --cc=bsegall@google.com \
    --cc=dengjun.su@mediatek.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=haiqiang.gong@mediatek.com \
    --cc=juri.lelli@redhat.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=matthias.bgg@gmail.com \
    --cc=mgorman@suse.de \
    --cc=mike.zhang@mediatek.com \
    --cc=mingo@redhat.com \
    --cc=peijun.huang@mediatek.com \
    --cc=rostedt@goodmis.org \
    --cc=vincent.guittot@linaro.org \
    --cc=vschneid@redhat.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