[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <550d2e4e-96c0-11de-f674-ea0fea870948@arm.com>
Date: Tue, 28 Mar 2017 15:45:59 +0200
From: Dietmar Eggemann <dietmar.eggemann@....com>
To: Vincent Guittot <vincent.guittot@...aro.org>
Cc: Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...nel.org>,
LKML <linux-kernel@...r.kernel.org>,
Matt Fleming <matt@...eblueprint.co.uk>,
Steven Rostedt <rostedt@...dmis.org>,
Morten Rasmussen <morten.rasmussen@....com>,
Juri Lelli <juri.lelli@....com>,
Patrick Bellasi <patrick.bellasi@....com>
Subject: Re: [RFC PATCH 0/5] CFS load tracking trace events
On 03/28/2017 12:05 PM, Vincent Guittot wrote:
> On 28 March 2017 at 08:35, Dietmar Eggemann <dietmar.eggemann@....com> wrote:
[...]
>> The following keys are used to identify the cfs scheduler brick:
>>
>> (1) Cpu number the cfs scheduler brick is attached to.
>>
>> (2) Task_group path and (css) id.
>>
>> (3) Task name and pid.
>
> Do you really need both path/name and id/pid ?
>
> The path/name looks quite intrusive so can't we just use id/pid ?
One problem is that all autogroups use id=0.
Another thing with task_groups is that dealing with path="/tg1/tg11" is
so much more intuitive than id="7".
IMHO, we do need task name and pid to be able to clearly identify a task
(same name/different pid or fork phase (forkee still has name of forker)).
You're right, the implementation with path is more complicated but I
guess that's worth it. We could get rid of 'id' though.
[...]
Powered by blists - more mailing lists