lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <f78a0d14-b0d4-b6ef-4d6b-561df5bd8a16@amd.com>
Date:   Thu, 24 Feb 2022 09:05:14 -0600
From:   Carlos Bilbao <carlos.bilbao@....com>
To:     Phil Auld <pauld@...hat.com>, mingo@...nel.org
Cc:     Peter Zijlstra <peterz@...radead.org>, juri.lelli@...hat.com,
        vincent.guittot@...aro.org, mingo@...hat.com,
        dietmar.eggemann@....com, rostedt@...dmis.org, bsegall@...gle.com,
        mgorman@...e.de, bristot@...hat.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] kernel/sched: Update schedstats when migrating threads

On 2/24/2022 8:03 AM, Phil Auld wrote:
> On Wed, Feb 23, 2022 at 10:13:50AM -0600 Carlos Bilbao wrote:
>> The kernel manages per-task scheduler statistics or schedstats. Update
>> function migrate_task_to() to increase the counter for migrations.
>>
>> Signed-off-by: Carlos Bilbao <carlos.bilbao@....com>
>> ---
>> Changelog:
>> 	v2: Update commit message, don't reinitialize sched fields.
>> ---
>>  kernel/sched/core.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
>> index fcf0c180617c..1360e501c737 100644
>> --- a/kernel/sched/core.c
>> +++ b/kernel/sched/core.c
>> @@ -8751,7 +8751,7 @@ 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 */
>> +	schedstat_inc(p->stats.nr_migrations_cold);
>>
> 
> I was going to give a reviewed by since I was looking at this,
> but I can't convince myself that nr_migrations_cold is right.
> This looks more like a "hot" migration (using stop_cpu to force
> it). But nr_migrations_cold is not incremented anywhere else so
> maybe it's a terminology thing.
> 
> Can you tell me why this is the right counter?
> 
>
The alternative to nr_migrations_cold is nr_forced_migrations, and since
we call this function in the context of NUMA balancing it didn't seem like
an appropriate fit at first glance. But documentation in this is scarce and 
I'm not very confident with the terminology either. Maybe Ingo Molar -the
original author of the structure- can clarify the specifics of these two 
counters so we can be sure about this? Maybe we need a new counter?

> Thanks,
> Phil
> 
> 
>>  	trace_sched_move_numa(p, curr_cpu, target_cpu);
>>  	return stop_one_cpu(curr_cpu, migration_cpu_stop, &arg);
>> -- 
>> 2.27.0
>>
> 

Thanks,
Carlos

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ