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

[bsegall]

Waiman Long <waiman.long@xxxxxxx> writes:

> On 12/02/2015 03:02 PM, bsegall@xxxxxxxxxx wrote:
>> Waiman Long<Waiman.Long@xxxxxxx>  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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/