All of lore.kernel.org
 help / color / mirror / Atom feed
From: Carlos Bilbao <carlos.bilbao@amd.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: juri.lelli@redhat.com, vincent.guittot@linaro.org,
	mingo@redhat.com, dietmar.eggemann@arm.com, rostedt@goodmis.org,
	bsegall@google.com, mgorman@suse.de, bristot@redhat.com,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] kernel/sched: Update schedstats when migrating threads
Date: Wed, 23 Feb 2022 09:14:45 -0600	[thread overview]
Message-ID: <aac8f860-c01f-bda0-9f1b-029b234213c2@amd.com> (raw)
In-Reply-To: <YhYKL4hxx4TNKHGD@hirez.programming.kicks-ass.net>

On 2/23/2022 4:19 AM, Peter Zijlstra wrote:
> On Wed, Jan 26, 2022 at 09:22:23AM -0600, Carlos Bilbao wrote:
>> The kernel manages per-task scheduler statistics or schedstats. Such
>> counters should be reinitialized when the thread is migrated to a
>> different core rq, except for the values recording number of migrations.
> 
> I'm confused, why should we reset schedstats on migrate? I'm thinking
> this breaks per-task, since tasks tend to bounce around quite a lot.
> 

Thanks for your comments, Peter. 

Looking at the documentation of schedstats I see that most values are 
actually linked to the particular CPU: time spent on the cpu, timeslices 
run on this cpu, number of times _something_ was called when the cpu was 
idle, and so forth. Those values lose their meaning after migration and we 
should reinitialize their counters. However, reviewing sched_statistics I 
identify two fields that we should definitely keep increasing even after 
migration (nr_migrations_cold, nr_forced_migrations).

So this patch will have to be upgraded if there's some other value(s) in
schedstats that we do not want to reinitialize either.

>> Signed-off-by: Carlos Bilbao <carlos.bilbao@amd.com>
>> ---
>>  kernel/sched/core.c | 10 +++++++++-
>>  1 file changed, 9 insertions(+), 1 deletion(-)
>>
>> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
>> index fe53e510e711..d64c2a290176 100644
>> --- a/kernel/sched/core.c
>> +++ b/kernel/sched/core.c
>> @@ -8757,6 +8757,7 @@ bool sched_smp_initialized __read_mostly;
>>  int migrate_task_to(struct task_struct *p, int target_cpu)
>>  {
>>  	struct migration_arg arg = { p, target_cpu };
>> +	uint64_t forced_migrations, migrations_cold;
>>  	int curr_cpu = task_cpu(p);
>>  
>>  	if (curr_cpu == target_cpu)
>> @@ -8765,7 +8766,14 @@ int migrate_task_to(struct task_struct *p, int target_cpu)
>>  	if (!cpumask_test_cpu(target_cpu, p->cpus_ptr))
>>  		return -EINVAL;
>>  
>> -	/* TODO: This is not properly updating schedstats */
>> +	if (schedstat_enabled()) {
>> +		forced_migrations = schedstat_val(p->stats.nr_forced_migrations);
>> +		migrations_cold = schedstat_val(p->stats.nr_migrations_cold);
>> +		memset(&p->stats, 0, sizeof(p->stats));
>> +		schedstat_set(p->stats.nr_forced_migrations, forced_migrations);
>> +		schedstat_set(p->stats.nr_migrations_cold, migrations_cold);
>> +		schedstat_inc(p->stats.nr_migrations_cold);
>> +	}
>>  
>>  	trace_sched_move_numa(p, curr_cpu, target_cpu);
>>  	return stop_one_cpu(curr_cpu, migration_cpu_stop, &arg);
>> -- 
>> 2.27.0
>>

Thanks,
Carlos

  reply	other threads:[~2022-02-23 15:14 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-26 15:22 [PATCH] kernel/sched: Update schedstats when migrating threads Carlos Bilbao
2022-02-22 16:32 ` Carlos Bilbao
2022-02-22 17:15   ` Steven Rostedt
2022-02-23 10:19 ` Peter Zijlstra
2022-02-23 15:14   ` Carlos Bilbao [this message]
2022-02-23 15:28     ` Phil Auld
2022-02-23 15:33       ` Carlos Bilbao
2022-02-23 15:47         ` Phil Auld
2022-02-23 15:59           ` Carlos Bilbao
2022-02-23 16:13             ` [PATCH v2] " Carlos Bilbao
2022-02-24 14:03               ` Phil Auld
2022-02-24 15:05                 ` Carlos Bilbao

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=aac8f860-c01f-bda0-9f1b-029b234213c2@amd.com \
    --to=carlos.bilbao@amd.com \
    --cc=bristot@redhat.com \
    --cc=bsegall@google.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=juri.lelli@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mgorman@suse.de \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=vincent.guittot@linaro.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.