[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1312293037.1147.181.camel@twins>
Date: Tue, 02 Aug 2011 15:50:37 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: "Jan H." Schönherr <schnhrr@...tu-berlin.de>
Cc: Ingo Molnar <mingo@...e.hu>, Paul Turner <pjt@...gle.com>,
"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
Dipankar Sarma <dipankar@...ibm.com>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH RFCv2 3/8] sched: Handle on_list ancestor in
list_add_leaf_cfs_rq()
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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists