lkml.org 
[lkml]   [2011]   [Aug]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH RFCv2 3/8] sched: Handle on_list ancestor in list_add_leaf_cfs_rq()
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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2011-08-03 22:47    [W:0.051 / U:0.780 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site