Messages in this thread | | | Date | Wed, 03 Aug 2011 22:44:13 +0200 | From | Jan Schönherr <> | Subject | Re: [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/
| |