[lkml]   [2011]   [Aug]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    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.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2011-08-03 22:47    [W:0.026 / U:6.072 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site