linux-kernel - Re: [PATCH] sched: fix exec_start/task

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAM4v1pPNfpB+DumFHhi2UZS97zgfBFHEwQYsmQ5E1c2gZFbBww@mail.gmail.com>
Date:	Fri, 16 May 2014 19:27:32 +0530
From:	Preeti Murthy <preeti.lkml@...il.com>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Ben Segall <bsegall@...gle.com>, Ingo Molnar <mingo@...hat.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Preeti U Murthy <preeti@...ux.vnet.ibm.com>
Subject: Re: [PATCH] sched: fix exec_start/task_hot on migrated tasks

Hi,

On Fri, May 16, 2014 at 1:34 PM, Peter Zijlstra <peterz@...radead.org> wrote:
> On Thu, May 15, 2014 at 03:59:20PM -0700, Ben Segall wrote:
>> task_hot checks exec_start on any runnable task, but if it has been
>> migrated since the it last ran, then exec_start is a clock_task from
>> another cpu. If the old cpu's clock_task was sufficiently far ahead of
>> this cpu's then the task will not be considered for another migration
>> until it has run. Instead reset exec_start whenever a task is migrated,
>> since it is presumably no longer hot anyway.
>>
>> Signed-off-by: Ben Segall <bsegall@...gle.com>
>> ---
>>  kernel/sched/fair.c |    3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
>> index 28ccf50..9f8dfeb 100644
>> --- a/kernel/sched/fair.c
>> +++ b/kernel/sched/fair.c
>> @@ -4544,6 +4544,9 @@ migrate_task_rq_fair(struct task_struct *p, int next_cpu)
>>               atomic_long_add(se->avg.load_avg_contrib,
>>                                               &cfs_rq->removed_load);
>>       }
>> +
>> +     /* We have migrated, no longer consider this task hot */
>> +     se.exec_start = 0;
>>  }
>
> 0 isn't strictly the right thing to do here, since the clock can wrap,
> but being wrong every ~585 years isn't too big an issue for this.

I don't understand this. Will setting it to 0 not indicate beginning
of ticking? So when you find out for how long the task has run, the
difference would be larger than what would have been had you
let exec_start be at its previous value of the old cpu's clock_task right?

Will not setting exec_start to the clock_task of the destination rq
during migration be better? This would be the closest we could
come to estimating the amount of time the task has run on this new
cpu while deciding task_hot or not no?

Regards
Preeti U Murthy

>
> Thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/