Skip to contentSkip to conversation

Move page_assign_page_cgroup to VM_BUG_ON in free_hot_cold_page

PATCH In review Balbir Singh 5 participants 11 messages Dec 19, 2007 – Dec 20, 2007

Subsystems (2)
Memory management Page allocator
lore
Share & tools
lore

Balbir Singh

author
#0 lore raw

PATCH 1/1 Move page_assign_page_cgroup to VM_BUG_ON in free_hot_cold_page

Based on the recommendation and observations of Hugh Dickins, page_cgroup_assign_cgroup() is not required. This patch replaces it with a VM_BUG_ON, so that we can catch them in free_hot_cold_page()

Signed-off-by Balbir Singh <[email protected]>

---

 mm/page_alloc.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
mm/page_alloc.c renamed from mm/page_alloc.c~memory-controller-move-to-bug-on-in-free_hot_cold_page +1 -1
diff -puN mm/page_alloc.c~memory-controller-move-to-bug-on-in-free_hot_cold_page mm/page_alloc.c
@@ -995,7 +995,7 @@ static void fastcall free_hot_cold_page(
 
 	if (!PageHighMem(page))
 		debug_check_no_locks_freed(page_address(page), PAGE_SIZE);
-	page_assign_page_cgroup(page, NULL);
+	VM_BUG_ON(page_get_page_cgroup(page));
 	arch_free_page(page, 0);
 	kernel_map_pages(page, 1, 0);

_

Signature · 4 lines
	Warm Regards,
	Balbir Singh
	Linux Technology Center
	IBM, ISTL
#1 lore raw

mm/page_alloc.c 2007-12-19 11:33:45.000000000 +0530 static void fastcall free_hot_cold_page( · line 1000

Quoted 11 lines · Balbir Singh

diff -puN mm/page_alloc.c~memory-controller-move-to-bug-on-in-free_hot_cold_page mm/page_alloc.c

mm/page_alloc.c 2007-12-19 11:33:45.000000000 +0530 renamed from mm/page_alloc.c~memory-controller-move-to-bug-on-in-free_hot_cold_page 2007-12-19 11:31:46.000000000 +0530 +1 -1
@@ -995,7 +995,7 @@ static void fastcall free_hot_cold_page(
 
        if (!PageHighMem(page))
                debug_check_no_locks_freed(page_address(page), PAGE_SIZE);
-       page_assign_page_cgroup(page, NULL);
+       VM_BUG_ON(page_get_page_cgroup(page));
        arch_free_page(page, 0);
        kernel_map_pages(page, 1, 0);

Hi Balbir,

You generally want to do these like:

	foo = page_assign_page_cgroup(page, NULL);
	VM_BUG_ON(foo);

Some embedded people have been known to optimize kernel size like this:

	#define VM_BUG_ON(x) do{}while(0)

-- Dave

#2 lore raw
Quoted 13 lines · Dave Hansen

mm/page_alloc.c 2007-12-19 11:33:45.000000000 +0530 static void fastcall free_hot_cold_page( · line 1000

Quoted 10 lines
mm/page_alloc.c 2007-12-19 11:33:45.000000000 +0530 renamed from mm/page_alloc.c~memory-controller-move-to-bug-on-in-free_hot_cold_page 2007-12-19 11:31:46.000000000 +0530 +1 -1
@@ -995,7 +995,7 @@ static void fastcall free_hot_cold_page(
 
        if (!PageHighMem(page))
                debug_check_no_locks_freed(page_address(page), PAGE_SIZE);
-       page_assign_page_cgroup(page, NULL);
+       VM_BUG_ON(page_get_page_cgroup(page));
        arch_free_page(page, 0);
        kernel_map_pages(page, 1, 0);

Hi Balbir,

Quoted 8 lines

You generally want to do these like:

	foo = page_assign_page_cgroup(page, NULL);
	VM_BUG_ON(foo);

Some embedded people have been known to optimize kernel size like this:

	#define VM_BUG_ON(x) do{}while(0)

Balbir's patch looks fine to me: I don't get your point there, Dave.

Hugh

#3 lore raw
Quoted 16 lines · Hugh Dickins
Quoted 15 lines · Dave Hansen

mm/page_alloc.c 2007-12-19 11:33:45.000000000 +0530 static void fastcall free_hot_cold_page( · line 1000

Quoted 10 lines
mm/page_alloc.c 2007-12-19 11:33:45.000000000 +0530 renamed from mm/page_alloc.c~memory-controller-move-to-bug-on-in-free_hot_cold_page 2007-12-19 11:31:46.000000000 +0530 +1 -1
@@ -995,7 +995,7 @@ static void fastcall free_hot_cold_page(
 
        if (!PageHighMem(page))
                debug_check_no_locks_freed(page_address(page), PAGE_SIZE);
-       page_assign_page_cgroup(page, NULL);
+       VM_BUG_ON(page_get_page_cgroup(page));
        arch_free_page(page, 0);
        kernel_map_pages(page, 1, 0);

Hi Balbir,

You generally want to do these like:

Quoted 8 lines
Quoted 6 lines
	foo = page_assign_page_cgroup(page, NULL);
	VM_BUG_ON(foo);

Some embedded people have been known to optimize kernel size like this:

	#define VM_BUG_ON(x) do{}while(0)

Balbir's patch looks fine to me: I don't get your point there, Dave.

There was a lengthy discussion here:
http://lkml.org/lkml/2007/12/14/131

on the merit of debug statements with side effects. But looking at our definition:

#ifdef CONFIG_DEBUG_VM
#define VM_BUG_ON(cond) BUG_ON(cond)
#else
#define VM_BUG_ON(condition) do { } while(0)
#endif

disabling CONFIG_DEBUG_VM breaks the code as proposed by Balbir in that it will no longer acquire the reference.

#4 lore raw
Quoted 14 lines · Peter Zijlstra
Quoted 13 lines · Hugh Dickins
Quoted 12 lines · Dave Hansen

mm/page_alloc.c static void fastcall free_hot_cold_page( · line 998

Quoted 2 lines
mm/page_alloc.c renamed from mm/page_alloc.c~memory-controller-move-to-bug-on-in-free_hot_cold_page +1 -1
-       page_assign_page_cgroup(page, NULL);
+       VM_BUG_ON(page_get_page_cgroup(page));

Hi Balbir,

You generally want to do these like:

	foo = page_assign_page_cgroup(page, NULL);
	VM_BUG_ON(foo);

Some embedded people have been known to optimize kernel size like this:

Quoted 8 lines
Quoted 3 lines
Quoted 1 line
	#define VM_BUG_ON(x) do{}while(0)

Balbir's patch looks fine to me: I don't get your point there, Dave.

There was a lengthy discussion here:
http://lkml.org/lkml/2007/12/14/131

on the merit of debug statements with side effects.

Of course, but what's the relevance?

Quoted 10 lines

But looking at our definition:

#ifdef CONFIG_DEBUG_VM
#define VM_BUG_ON(cond) BUG_ON(cond)
#else
#define VM_BUG_ON(condition) do { } while(0)
#endif

disabling CONFIG_DEBUG_VM breaks the code as proposed by Balbir in that it will no longer acquire the reference.

But what reference?

struct page_cgroup *page_get_page_cgroup(struct page *page)

{
	return (struct page_cgroup *)
		(page->page_cgroup & ~PAGE_CGROUP_LOCK);
}

I guess the issue is that often a "get" function has a complementary "put" function, but this isn't one of them. Would page_page_cgroup be a better name, perhaps? I don't know.

Hugh

#5 lore raw
Quoted 40 lines · Hugh Dickins
Quoted 14 lines · Peter Zijlstra
Quoted 13 lines · Hugh Dickins
Quoted 12 lines · Dave Hansen

mm/page_alloc.c static void fastcall free_hot_cold_page( · line 998

Quoted 2 lines
mm/page_alloc.c renamed from mm/page_alloc.c~memory-controller-move-to-bug-on-in-free_hot_cold_page +1 -1
-       page_assign_page_cgroup(page, NULL);
+       VM_BUG_ON(page_get_page_cgroup(page));

Hi Balbir,

You generally want to do these like:

	foo = page_assign_page_cgroup(page, NULL);
	VM_BUG_ON(foo);

Some embedded people have been known to optimize kernel size like this:

Quoted 8 lines
Quoted 3 lines
Quoted 1 line
	#define VM_BUG_ON(x) do{}while(0)

Balbir's patch looks fine to me: I don't get your point there, Dave.

There was a lengthy discussion here:
http://lkml.org/lkml/2007/12/14/131

on the merit of debug statements with side effects.

Of course, but what's the relevance?

Quoted 10 lines

But looking at our definition:

#ifdef CONFIG_DEBUG_VM
#define VM_BUG_ON(cond) BUG_ON(cond)
#else
#define VM_BUG_ON(condition) do { } while(0)
#endif

disabling CONFIG_DEBUG_VM breaks the code as proposed by Balbir in that it will no longer acquire the reference.

But what reference?

struct page_cgroup *page_get_page_cgroup(struct page *page)

Quoted 8 lines
{
	return (struct page_cgroup *)
		(page->page_cgroup & ~PAGE_CGROUP_LOCK);
}

I guess the issue is that often a "get" function has a complementary "put" function, but this isn't one of them. Would page_page_cgroup be a better name, perhaps? I don't know.

Ah, yes, I mistakenly assumed it was a reference get. In that case I stand corrected and do not have any objections.

author
#6 lore raw
Quoted 41 lines · Peter Zijlstra
Quoted 40 lines · Hugh Dickins
Quoted 11 lines · Peter Zijlstra
Quoted 10 lines · Hugh Dickins
Quoted 9 lines · Dave Hansen

mm/page_alloc.c static void fastcall free_hot_cold_page( · line 998

Quoted 2 lines
mm/page_alloc.c renamed from mm/page_alloc.c~memory-controller-move-to-bug-on-in-free_hot_cold_page +1 -1
-       page_assign_page_cgroup(page, NULL);
+       VM_BUG_ON(page_get_page_cgroup(page));

Hi Balbir,

You generally want to do these like:

	foo = page_assign_page_cgroup(page, NULL);
	VM_BUG_ON(foo);
Quoted 8 lines
Quoted 4 lines
Quoted 3 lines

Some embedded people have been known to optimize kernel size like this:

	#define VM_BUG_ON(x) do{}while(0)

Balbir's patch looks fine to me: I don't get your point there, Dave.

There was a lengthy discussion here:
http://lkml.org/lkml/2007/12/14/131

on the merit of debug statements with side effects.

Of course, but what's the relevance?

Quoted 10 lines

But looking at our definition:

#ifdef CONFIG_DEBUG_VM
#define VM_BUG_ON(cond) BUG_ON(cond)
#else
#define VM_BUG_ON(condition) do { } while(0)
#endif

disabling CONFIG_DEBUG_VM breaks the code as proposed by Balbir in that it will no longer acquire the reference.

But what reference?

struct page_cgroup *page_get_page_cgroup(struct page *page)

{
	return (struct page_cgroup *)
		(page->page_cgroup & ~PAGE_CGROUP_LOCK);
}
Quoted 7 lines
Quoted 3 lines

I guess the issue is that often a "get" function has a complementary "put" function, but this isn't one of them. Would page_page_cgroup be a better name, perhaps? I don't know.

Ah, yes, I mistakenly assumed it was a reference get. In that case I stand corrected and do not have any objections.

I was going to say the same thing, page_get_page_cgroup() does not hold any references. May be _get_ in the name is confusing.

Signature · 4 lines
	Warm Regards,
	Balbir Singh
	Linux Technology Center
	IBM, ISTL
#7 lore raw
Quoted 3 lines · Balbir Singh

I was going to say the same thing, page_get_page_cgroup() does not hold any references. May be _get_ in the name is confusing.

OK, you three had the entire conversation outing me before I even fot to respond! :)

Yeah, I thought it was a refcount acquisition. Balbir, it's fine the way it stands (except for the slightly confusing name).

-- Dave

maintainer
#8 lore raw
In reply to Balbir Singh
Quoted 10 lines · On Thu, 20 Dec 2007 21:54:15 +0530 Balbir Singh <[email protected]>…
Quoted 10 lines
Quoted 9 lines

struct page_cgroup *page_get_page_cgroup(struct page *page)

{
	return (struct page_cgroup *)
		(page->page_cgroup & ~PAGE_CGROUP_LOCK);
}

I guess the issue is that often a "get" function has a complementary "put" function, but this isn't one of them. Would page_page_cgroup be a better name, perhaps? I don't know.

Quoted 6 lines
Quoted 3 lines

Ah, yes, I mistakenly assumed it was a reference get. In that case I stand corrected and do not have any objections.

I was going to say the same thing, page_get_page_cgroup() does not hold any references. May be _get_ in the name is confusing.

It is a bit unconventional. page_cgroup()?

#9 lore raw
Quoted 5 lines · Andrew Morton
Quoted 2 lines · On Thu, 20 Dec 2007 21:54:15 +0530 Balbir Singh <[email protected]>…

I was going to say the same thing, page_get_page_cgroup() does not hold any references. May be _get_ in the name is confusing.

It is a bit unconventional. page_cgroup()?

Seems ideal to me
(though there is some argument for page_page_cgroup(), weird as it is).

Hugh

author
#10 lore raw
Quoted 10 lines · Hugh Dickins
Quoted 4 lines · Andrew Morton
Quoted 2 lines · On Thu, 20 Dec 2007 21:54:15 +0530 Balbir Singh <[email protected]>…

I was going to say the same thing, page_get_page_cgroup() does not hold any references. May be _get_ in the name is confusing.

It is a bit unconventional. page_cgroup()?

Seems ideal to me
(though there is some argument for page_page_cgroup(), weird as it is).

Hugh

Sounds good to me as well, except that it sounds like a constructor :-) I'll try and make the changes and submit a patch. I am in the middle of losing control_type now (based on Hugh's comments)

Signature · 4 lines
	Warm Regards,
	Balbir Singh
	Linux Technology Center
	IBM, ISTL