Messages in this thread | | | Subject | Re: [PATCH v5 07/10] sched/irq: add irq utilization tracking | From | Dietmar Eggemann <> | Date | Thu, 7 Jun 2018 11:06:29 +0200 |
| |
On 06/07/2018 10:44 AM, Vincent Guittot wrote: > On 7 June 2018 at 10:29, Dietmar Eggemann <dietmar.eggemann@arm.com> wrote: >> On 06/06/2018 06:06 PM, Vincent Guittot wrote: >>> >>> Hi Dietmar, >>> >>> Sorry for the late answer >>> >>> On 31 May 2018 at 18:54, Dietmar Eggemann <dietmar.eggemann@arm.com> >>> wrote: >>>> >>>> On 05/30/2018 08:45 PM, Vincent Guittot wrote: >>>>> >>>>> Hi Dietmar, >>>>> >>>>> On 30 May 2018 at 17:55, Dietmar Eggemann <dietmar.eggemann@arm.com> >>>>> wrote: >>>>>> >>>>>> On 05/25/2018 03:12 PM, Vincent Guittot wrote:
[...]
>> Can't buy this argument though because this is true with the current >> implementation as well since the 'decay load sum' - 'accrue load sum' >> sequence is not atomic. > > it's not a problem that the _sum variable are updated in different > step because there are internal variable > Only util_avg is used "outside" and the latter is updated after both > idle and running steps have been applied
You're right here!
>> What about calling update_irq_load_avg(rq, 0) in update_rq_clock_task() if >> (irq_delta + steal) eq. 0 and sched_feat(NONTASK_CAPACITY) eq. true in this >> #ifdef CONFIG_XXX_TIME_ACCOUNTING block? > > update_irq_load_avg(rq, 0) is called in update_blocked_averages to > decay smoothly like other blocked signals and replace the need to call > update_irq_load_avg(rq, 0) for every call to update_rq_clock_task() > which can be significant
OK.
>> Maintaining a irq/steal time signal makes only sense if at least one of the >> CONFIG_XXX_TIME_ACCOUNTING is set and NONTASK_CAPACITY is true. The call to >> update_irq_load_avg() in update_blocked_averages() isn't guarded my them. > > good point
[...]
| |