Thread (96 messages) 96 messages, 8 authors, 2012-08-08

Re: [PATCH 09/11] memcg: propagate kmem limiting information to children

From: Andrew Morton <akpm@linux-foundation.org>
Date: 2012-06-25 23:22:03
Also in: linux-mm, lkml

On Tue, 26 Jun 2012 02:36:27 +0400
Glauber Costa [off-list ref] wrote:
On 06/25/2012 10:29 PM, Tejun Heo wrote:
quoted
Feeling like a nit pervert but..

On Mon, Jun 25, 2012 at 06:15:26PM +0400, Glauber Costa wrote:
quoted
@@ -287,7 +287,11 @@ struct mem_cgroup {
  	 * Should the accounting and control be hierarchical, per subtree?
  	 */
  	bool use_hierarchy;
-	bool kmem_accounted;
+	/*
+	 * bit0: accounted by this cgroup
+	 * bit1: accounted by a parent.
+	 */
+	volatile unsigned long kmem_accounted;
Is the volatile declaration really necessary?  Why is it necessary?
Why no comment explaining it?
Seems to be required by set_bit and friends. gcc will complain if it is 
not volatile (take a look at the bit function headers)
That would be a broken gcc.  We run test_bit()/set_bit() and friends
against plain old `unsigned long' in thousands of places.  There's
nothing special about this one!


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help