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

[Peter Zijlstra]

On Wed, 2011-07-27 at 21:10 +0200, Jan H. SchÃnherr wrote:
> +       /*
> +        * Carefully collect leaf-cfs entries.
> +        *
> +        * There are basically two cases:
> +        * 1. cfs_rq has not yet been on the leaf-list.
> +        * 2. cfs_rq has been deleted previously from the leaf_list.
> +        *
> +        * In case 2, we might still have concurrent readers.
> +        *
> +        * Therefore, the requirements of list_add_tail_nobackref() are
> +        * fulfilled:
> +        *
> +        * a) If there are concurrent readers, ->next must lead back to the
> +        *    list.
> +        *
> +        *    We can only have readers after case 2. After case 2, only case 2
> +        *    can follow. The next pointers of case 2 nodes always lead back to
> +        *    the list.
> +        *
> +        * b) If there are concurrent readers, ->next must not lead to any
> +        *    already collected node.
> +        *
> +        *    As we collect nodes always bottom-up, all already collected nodes
> +        *    must be below this node in the task group hierarchy.  The
> +        *    ordering constraint of the leaf list guarantees that next
> +        *    pointers only lead to nodes further up in the hierarchy (or to
> +        *    unrelated nodes). Neither deleting nodes nor the manipulations
> +        *    done here change that. Thus, we cannot reach an already collected
> +        *    node.
> +        *
> +        * 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.

Bit of a barrier to shooting your foot off or so..
--
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/