Re: [PATCH RFCv2 3/8] sched: Handle on_list ancestor in list_add_leaf_cfs_rq()

[Jan SchÃnherr]

Am 02.08.2011 15:50, schrieb Peter Zijlstra:
> On Wed, 2011-07-27 at 21:10 +0200, Jan H. SchÃnherr wrote:
[...]
>> +        * c) If there are concurrent readers, they must already know this
>> +        *    node.
>> +        *
>> +        *    If we have to add case 1 nodes, they are collected in the
>> +        *    beginning and cannot be reached by readers until they are
>> +        *    spliced. Furthermore, after they are spliced, we will not
>> +        *    encounter more case 1 nodes higher up in the task group
>> +        *    hierarchy. For this reason any reader on an earlier collected
>> +        *    case 2 node must know all nodes that we collect later.
>> +        */
>> +       list_add_tail_nobackref(&cfs_rq->leaf_cfs_rq_list, leaf_cfs_rqs); 
> 
> I think there's an argument for not adding _nobackref and simply
> open-coding the operation here. Could there possibly be another user
> that wants this? 
> 
> Furthermore, since its tricky like hell every site would want a comment
> like the above explaining exactly what and why, and when you put in that
> much effort, you might as well write the list-op itself too.

Will do.

However, when reassigning next-pointers of deleted nodes to not deleted
nodes (e. g. the list head itself) as outlined in the other mail,
we'll have to use rcu-aware assignments to really prevent the race with
physical deletion. Therefore, the condition c) still listed above
will be unnecessary, then.

Regards
Jan
--
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/