Re: [PATCH v2 2/3] sched/fair: Move hot load_avg into its own cacheline

bsegall
2015-12-03T19:41:08Z

Waiman Long <waiman.long@hpe.com> writes:

> On 12/02/2015 03:02 PM, bsegall@google.com wrote:
>> Waiman Long<Waiman.Long@hpe.com> writes:
>>> diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
>>> index efd3bfc..e679895 100644
>>> --- a/kernel/sched/sched.h
>>> +++ b/kernel/sched/sched.h
>>> @@ -248,7 +248,12 @@ struct task_group {
>>> unsigned long shares;
>>>
>>> #ifdef CONFIG_SMP
>>> - atomic_long_t load_avg;
>>> + /*
>>> + * load_avg can be heavily contended at clock tick time, so put
>>> + * it in its own cacheline separated from the fields above which
>>> + * will also be accessed at each tick.
>>> + */
>>> + atomic_long_t load_avg ____cacheline_aligned;
>>> #endif
>>> #endif
>> I suppose the question is if it would be better to just move this to
>> wind up on a separate cacheline without the extra empty space, though it
>> would likely be more fragile and unclear.
>
> I have been thinking about that too. The problem is anything that will be in the
> same cacheline as load_avg and have to be accessed at clock click time will
> cause the same contention problem. In the current layout, the fields after
> load_avg are the rt stuff as well some list head structure and pointers. The rt
> stuff should be kind of mutually exclusive of the CFS load_avg in term of usage.
> The list head structure and pointers don't seem to be that frequently accessed.
> So it is the right place to start a new cacheline boundary.
>
> Cheers,
> Longman

Yeah, this is a good place to start a new boundary, I was just saying
you could probably remove the empty space by reordering fields, but that
would be a less logical ordering in terms of programmer clarity.