[RFC] Restrict size of page_cgroup->flags

[RFC] Restrict size of page_cgroup->flags

[Balbir Singh]

I propose restricting page_cgroup.flags to 16 bits. The patch for the
same is below. Comments?


Restrict the bits usage in page_cgroup.flags

From: Balbir Singh <balbir@linux.vnet.ibm.com>

Restricting the flags helps control growth of the flags unbound.
Restriciting it to 16 bits gives us the possibility of merging
cgroup id with flags (atomicity permitting) and saving a whole
long word in page_cgroup

Signed-off-by: Balbir Singh <balbir@linux.vnet.ibm.com>
---

 include/linux/page_cgroup.h |    3 +++
 mm/page_cgroup.c            |    1 +
 2 files changed, 4 insertions(+), 0 deletions(-)


diff --git a/include/linux/page_cgroup.h b/include/linux/page_cgroup.h
index 872f6b1..10c37b4 100644
--- a/include/linux/page_cgroup.h
+++ b/include/linux/page_cgroup.h
@@ -44,8 +44,11 @@ enum {
 	PCG_FILE_WRITEBACK, /* page is under writeback */
 	PCG_FILE_UNSTABLE_NFS, /* page is NFS unstable */
 	PCG_MIGRATION, /* under page migration */
+	PCG_MAX_NR,
 };
 
+#define PCG_MAX_BIT_SIZE	16
+
 #define TESTPCGFLAG(uname, lname)			\
 static inline int PageCgroup##uname(struct page_cgroup *pc)	\
 	{ return test_bit(PCG_##lname, &pc->flags); }
diff --git a/mm/page_cgroup.c b/mm/page_cgroup.c
index 5bffada..e16ad2e 100644
--- a/mm/page_cgroup.c
+++ b/mm/page_cgroup.c
@@ -258,6 +258,7 @@ void __init page_cgroup_init(void)
 	unsigned long pfn;
 	int fail = 0;
 
+	BUILD_BUG_ON(PCG_MAX_NR >= PCG_MAX_BIT_SIZE);
 	if (mem_cgroup_disabled())
 		return;
 

-- 
	Three Cheers,
	Balbir

--
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>

Re: [RFC] Restrict size of page_cgroup->flags

[KAMEZAWA Hiroyuki]

On Wed, 6 Oct 2010 19:53:14 +0530
Balbir Singh <balbir@linux.vnet.ibm.com> wrote:

> I propose restricting page_cgroup.flags to 16 bits. The patch for the
> same is below. Comments?
> 
> 
> Restrict the bits usage in page_cgroup.flags
> 
> From: Balbir Singh <balbir@linux.vnet.ibm.com>
> 
> Restricting the flags helps control growth of the flags unbound.
> Restriciting it to 16 bits gives us the possibility of merging
> cgroup id with flags (atomicity permitting) and saving a whole
> long word in page_cgroup
> 
> Signed-off-by: Balbir Singh <balbir@linux.vnet.ibm.com>

Doesn't make sense until you show the usage of existing bits.
And I guess 16bit may be too large on 32bit systems.

Nack for now.

Thanks,
-Kame

--
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>

Re: [RFC] Restrict size of page_cgroup->flags

[Balbir Singh]

* KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> [2010-10-07 08:58:58]:

> On Wed, 6 Oct 2010 19:53:14 +0530
> Balbir Singh <balbir@linux.vnet.ibm.com> wrote:
> 
> > I propose restricting page_cgroup.flags to 16 bits. The patch for the
> > same is below. Comments?
> > 
> > 
> > Restrict the bits usage in page_cgroup.flags
> > 
> > From: Balbir Singh <balbir@linux.vnet.ibm.com>
> > 
> > Restricting the flags helps control growth of the flags unbound.
> > Restriciting it to 16 bits gives us the possibility of merging
> > cgroup id with flags (atomicity permitting) and saving a whole
> > long word in page_cgroup
> > 
> > Signed-off-by: Balbir Singh <balbir@linux.vnet.ibm.com>
> 
> Doesn't make sense until you show the usage of existing bits.

??

> And I guess 16bit may be too large on 32bit systems.

too large on 32 bit systems? My intention is to keep the flags to 16
bits and then use cgroup id for the rest and see if we can remove
mem_cgroup pointer

> Nack for now.
>

The issue is - do you see further growth of flags?
 
> Thanks,
> -Kame
> 

-- 
	Three Cheers,
	Balbir

--
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>

Re: [RFC] Restrict size of page_cgroup->flags

[KAMEZAWA Hiroyuki]

On Thu, 7 Oct 2010 08:42:04 +0530
Balbir Singh <balbir@linux.vnet.ibm.com> wrote:

> * KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> [2010-10-07 08:58:58]:
> 
> > On Wed, 6 Oct 2010 19:53:14 +0530
> > Balbir Singh <balbir@linux.vnet.ibm.com> wrote:
> > 
> > > I propose restricting page_cgroup.flags to 16 bits. The patch for the
> > > same is below. Comments?
> > > 
> > > 
> > > Restrict the bits usage in page_cgroup.flags
> > > 
> > > From: Balbir Singh <balbir@linux.vnet.ibm.com>
> > > 
> > > Restricting the flags helps control growth of the flags unbound.
> > > Restriciting it to 16 bits gives us the possibility of merging
> > > cgroup id with flags (atomicity permitting) and saving a whole
> > > long word in page_cgroup
> > > 
> > > Signed-off-by: Balbir Singh <balbir@linux.vnet.ibm.com>
> > 
> > Doesn't make sense until you show the usage of existing bits.
> 
> ??
> 
Limiting something for NOT EXISTING PATCH doesn't make sense, in general.


> > And I guess 16bit may be too large on 32bit systems.
> 
> too large on 32 bit systems? My intention is to keep the flags to 16
> bits and then use cgroup id for the rest and see if we can remove
> mem_cgroup pointer
> 

You can't use flags field to store mem_cgroup_id while we use lock bit on it.
We have to store something more stable...as pfn or node-id or zone-id.

It's very racy. 

Thanks,
-Kame

--
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>

Re: [RFC] Restrict size of page_cgroup->flags

[Balbir Singh]

* KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> [2010-10-07 12:18:16]:

> On Thu, 7 Oct 2010 08:42:04 +0530
> Balbir Singh <balbir@linux.vnet.ibm.com> wrote:
> 
> > * KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> [2010-10-07 08:58:58]:
> > 
> > > On Wed, 6 Oct 2010 19:53:14 +0530
> > > Balbir Singh <balbir@linux.vnet.ibm.com> wrote:
> > > 
> > > > I propose restricting page_cgroup.flags to 16 bits. The patch for the
> > > > same is below. Comments?
> > > > 
> > > > 
> > > > Restrict the bits usage in page_cgroup.flags
> > > > 
> > > > From: Balbir Singh <balbir@linux.vnet.ibm.com>
> > > > 
> > > > Restricting the flags helps control growth of the flags unbound.
> > > > Restriciting it to 16 bits gives us the possibility of merging
> > > > cgroup id with flags (atomicity permitting) and saving a whole
> > > > long word in page_cgroup
> > > > 
> > > > Signed-off-by: Balbir Singh <balbir@linux.vnet.ibm.com>
> > > 
> > > Doesn't make sense until you show the usage of existing bits.
> > 
> > ??
> > 
> Limiting something for NOT EXISTING PATCH doesn't make sense, in general.
> 
> 
> > > And I guess 16bit may be too large on 32bit systems.
> > 
> > too large on 32 bit systems? My intention is to keep the flags to 16
> > bits and then use cgroup id for the rest and see if we can remove
> > mem_cgroup pointer
> > 
> 
> You can't use flags field to store mem_cgroup_id while we use lock bit on it.
> We have to store something more stable...as pfn or node-id or zone-id.
> 
> It's very racy. 
>

Yes, correct it is racy, there is no easy way from what I know we can write
the upper 16 bits of the flag without affecting the lower 16 bits, if
the 16 bits are changing. One of the techniques could be to have lock
for the unsigned long word itself - but I don't know what performance
overhead that would add. Having said that I would like to explore
techniques that allow me to merge the two.

-- 
	Three Cheers,
	Balbir

--
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>

Re: [RFC] Restrict size of page_cgroup->flags

[KAMEZAWA Hiroyuki]

On Thu, 7 Oct 2010 09:26:08 +0530
Balbir Singh <balbir@linux.vnet.ibm.com> wrote:

> * KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> [2010-10-07 12:18:16]:
> 
> > On Thu, 7 Oct 2010 08:42:04 +0530
> > Balbir Singh <balbir@linux.vnet.ibm.com> wrote:
> > 
> > > * KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> [2010-10-07 08:58:58]:
> > > 
> > > > On Wed, 6 Oct 2010 19:53:14 +0530
> > > > Balbir Singh <balbir@linux.vnet.ibm.com> wrote:
> > > > 
> > > > > I propose restricting page_cgroup.flags to 16 bits. The patch for the
> > > > > same is below. Comments?
> > > > > 
> > > > > 
> > > > > Restrict the bits usage in page_cgroup.flags
> > > > > 
> > > > > From: Balbir Singh <balbir@linux.vnet.ibm.com>
> > > > > 
> > > > > Restricting the flags helps control growth of the flags unbound.
> > > > > Restriciting it to 16 bits gives us the possibility of merging
> > > > > cgroup id with flags (atomicity permitting) and saving a whole
> > > > > long word in page_cgroup
> > > > > 
> > > > > Signed-off-by: Balbir Singh <balbir@linux.vnet.ibm.com>
> > > > 
> > > > Doesn't make sense until you show the usage of existing bits.
> > > 
> > > ??
> > > 
> > Limiting something for NOT EXISTING PATCH doesn't make sense, in general.
> > 
> > 
> > > > And I guess 16bit may be too large on 32bit systems.
> > > 
> > > too large on 32 bit systems? My intention is to keep the flags to 16
> > > bits and then use cgroup id for the rest and see if we can remove
> > > mem_cgroup pointer
> > > 
> > 
> > You can't use flags field to store mem_cgroup_id while we use lock bit on it.
> > We have to store something more stable...as pfn or node-id or zone-id.
> > 
> > It's very racy. 
> >
> 
> Yes, correct it is racy, there is no easy way from what I know we can write
> the upper 16 bits of the flag without affecting the lower 16 bits, if
> the 16 bits are changing. One of the techniques could be to have lock
> for the unsigned long word itself - but I don't know what performance
> overhead that would add. Having said that I would like to explore
> techniques that allow me to merge the two.
> 

to store pfn, we need to limit under 12bit.
I'll schedule my patch if dirty_ratio one goes.

Thanks,
-Kame


--
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>

Re: [RFC] Restrict size of page_cgroup->flags

[Balbir Singh]

* KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> [2010-10-07 13:22:33]:

> On Thu, 7 Oct 2010 09:26:08 +0530
> Balbir Singh <balbir@linux.vnet.ibm.com> wrote:
> 
> > * KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> [2010-10-07 12:18:16]:
> > 
> > > On Thu, 7 Oct 2010 08:42:04 +0530
> > > Balbir Singh <balbir@linux.vnet.ibm.com> wrote:
> > > 
> > > > * KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> [2010-10-07 08:58:58]:
> > > > 
> > > > > On Wed, 6 Oct 2010 19:53:14 +0530
> > > > > Balbir Singh <balbir@linux.vnet.ibm.com> wrote:
> > > > > 
> > > > > > I propose restricting page_cgroup.flags to 16 bits. The patch for the
> > > > > > same is below. Comments?
> > > > > > 
> > > > > > 
> > > > > > Restrict the bits usage in page_cgroup.flags
> > > > > > 
> > > > > > From: Balbir Singh <balbir@linux.vnet.ibm.com>
> > > > > > 
> > > > > > Restricting the flags helps control growth of the flags unbound.
> > > > > > Restriciting it to 16 bits gives us the possibility of merging
> > > > > > cgroup id with flags (atomicity permitting) and saving a whole
> > > > > > long word in page_cgroup
> > > > > > 
> > > > > > Signed-off-by: Balbir Singh <balbir@linux.vnet.ibm.com>
> > > > > 
> > > > > Doesn't make sense until you show the usage of existing bits.
> > > > 
> > > > ??
> > > > 
> > > Limiting something for NOT EXISTING PATCH doesn't make sense, in general.
> > > 
> > > 
> > > > > And I guess 16bit may be too large on 32bit systems.
> > > > 
> > > > too large on 32 bit systems? My intention is to keep the flags to 16
> > > > bits and then use cgroup id for the rest and see if we can remove
> > > > mem_cgroup pointer
> > > > 
> > > 
> > > You can't use flags field to store mem_cgroup_id while we use lock bit on it.
> > > We have to store something more stable...as pfn or node-id or zone-id.
> > > 
> > > It's very racy. 
> > >
> > 
> > Yes, correct it is racy, there is no easy way from what I know we can write
> > the upper 16 bits of the flag without affecting the lower 16 bits, if
> > the 16 bits are changing. One of the techniques could be to have lock
> > for the unsigned long word itself - but I don't know what performance
> > overhead that would add. Having said that I would like to explore
> > techniques that allow me to merge the two.
> > 
> 
> to store pfn, we need to limit under 12bit.
> I'll schedule my patch if dirty_ratio one goes.
>

cool! We'll redo the patch then and lets make this work. We'll need to
see how many bits we need for section/node/zone to do pc_to_pfn() and
pfn_to_page().

-- 
	Three Cheers,
	Balbir

--
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>

Re: [RFC] Restrict size of page_cgroup->flags

[KAMEZAWA Hiroyuki]

On Thu, 7 Oct 2010 11:01:17 +0530
Balbir Singh <balbir@linux.vnet.ibm.com> wrote:

> * KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> [2010-10-07 13:22:33]:
> 
> > On Thu, 7 Oct 2010 09:26:08 +0530
> > Balbir Singh <balbir@linux.vnet.ibm.com> wrote:
> > 
> > > * KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> [2010-10-07 12:18:16]:
> > > 
> > > > On Thu, 7 Oct 2010 08:42:04 +0530
> > > > Balbir Singh <balbir@linux.vnet.ibm.com> wrote:
> > > > 
> > > > > * KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> [2010-10-07 08:58:58]:
> > > > > 
> > > > > > On Wed, 6 Oct 2010 19:53:14 +0530
> > > > > > Balbir Singh <balbir@linux.vnet.ibm.com> wrote:
> > > > > > 
> > > > > > > I propose restricting page_cgroup.flags to 16 bits. The patch for the
> > > > > > > same is below. Comments?
> > > > > > > 
> > > > > > > 
> > > > > > > Restrict the bits usage in page_cgroup.flags
> > > > > > > 
> > > > > > > From: Balbir Singh <balbir@linux.vnet.ibm.com>
> > > > > > > 
> > > > > > > Restricting the flags helps control growth of the flags unbound.
> > > > > > > Restriciting it to 16 bits gives us the possibility of merging
> > > > > > > cgroup id with flags (atomicity permitting) and saving a whole
> > > > > > > long word in page_cgroup
> > > > > > > 
> > > > > > > Signed-off-by: Balbir Singh <balbir@linux.vnet.ibm.com>
> > > > > > 
> > > > > > Doesn't make sense until you show the usage of existing bits.
> > > > > 
> > > > > ??
> > > > > 
> > > > Limiting something for NOT EXISTING PATCH doesn't make sense, in general.
> > > > 
> > > > 
> > > > > > And I guess 16bit may be too large on 32bit systems.
> > > > > 
> > > > > too large on 32 bit systems? My intention is to keep the flags to 16
> > > > > bits and then use cgroup id for the rest and see if we can remove
> > > > > mem_cgroup pointer
> > > > > 
> > > > 
> > > > You can't use flags field to store mem_cgroup_id while we use lock bit on it.
> > > > We have to store something more stable...as pfn or node-id or zone-id.
> > > > 
> > > > It's very racy. 
> > > >
> > > 
> > > Yes, correct it is racy, there is no easy way from what I know we can write
> > > the upper 16 bits of the flag without affecting the lower 16 bits, if
> > > the 16 bits are changing. One of the techniques could be to have lock
> > > for the unsigned long word itself - but I don't know what performance
> > > overhead that would add. Having said that I would like to explore
> > > techniques that allow me to merge the two.
> > > 
> > 
> > to store pfn, we need to limit under 12bit.
> > I'll schedule my patch if dirty_ratio one goes.
> >
> 
> cool! We'll redo the patch then and lets make this work. We'll need to
> see how many bits we need for section/node/zone to do pc_to_pfn() and
> pfn_to_page().
> 

As far as I know now,

!CONFIG_HIGHMEM -> we can store pfn.
CONFIG_HIGHMEM && CONFIG_SPARSEMEM -> we can store section
CONFIG_HIGHMEM && !CONFIG_SPARSEMEM -> we can store node-id
CONFIG_HIGHMEM && CONFIG_SPARSEMEM_VMEMMAP -> there is no arch.

I think we can do.

-Kame


--
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>

Re: [RFC] Restrict size of page_cgroup->flags

[Daisuke Nishimura]

On Thu, 7 Oct 2010 13:22:33 +0900
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote:

> On Thu, 7 Oct 2010 09:26:08 +0530
> Balbir Singh <balbir@linux.vnet.ibm.com> wrote:
> 
> > * KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> [2010-10-07 12:18:16]:
> > 
> > > On Thu, 7 Oct 2010 08:42:04 +0530
> > > Balbir Singh <balbir@linux.vnet.ibm.com> wrote:
> > > 
> > > > * KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> [2010-10-07 08:58:58]:
> > > > 
> > > > > On Wed, 6 Oct 2010 19:53:14 +0530
> > > > > Balbir Singh <balbir@linux.vnet.ibm.com> wrote:
> > > > > 
> > > > > > I propose restricting page_cgroup.flags to 16 bits. The patch for the
> > > > > > same is below. Comments?
> > > > > > 
> > > > > > 
> > > > > > Restrict the bits usage in page_cgroup.flags
> > > > > > 
> > > > > > From: Balbir Singh <balbir@linux.vnet.ibm.com>
> > > > > > 
> > > > > > Restricting the flags helps control growth of the flags unbound.
> > > > > > Restriciting it to 16 bits gives us the possibility of merging
> > > > > > cgroup id with flags (atomicity permitting) and saving a whole
> > > > > > long word in page_cgroup
> > > > > > 
> > > > > > Signed-off-by: Balbir Singh <balbir@linux.vnet.ibm.com>
> > > > > 
> > > > > Doesn't make sense until you show the usage of existing bits.
> > > > 
> > > > ??
> > > > 
> > > Limiting something for NOT EXISTING PATCH doesn't make sense, in general.
> > > 
> > > 
> > > > > And I guess 16bit may be too large on 32bit systems.
> > > > 
> > > > too large on 32 bit systems? My intention is to keep the flags to 16
> > > > bits and then use cgroup id for the rest and see if we can remove
> > > > mem_cgroup pointer
> > > > 
> > > 
> > > You can't use flags field to store mem_cgroup_id while we use lock bit on it.
> > > We have to store something more stable...as pfn or node-id or zone-id.
> > > 
> > > It's very racy. 
> > >
> > 
> > Yes, correct it is racy, there is no easy way from what I know we can write
> > the upper 16 bits of the flag without affecting the lower 16 bits, if
> > the 16 bits are changing. One of the techniques could be to have lock
> > for the unsigned long word itself - but I don't know what performance
> > overhead that would add. Having said that I would like to explore
> > techniques that allow me to merge the two.
> > 
> 
> to store pfn, we need to limit under 12bit.
I'm sorry if I miss something, but is it valid in PAE case too ?
I think it would be better to store section id(or node id) rather than pfn.

> I'll schedule my patch if dirty_ratio one goes.
> 
Agreed. I think we should do dirty_ratio patches first.


Thanks,
Daisuke Nishimura.

--
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>

Re: [RFC] Restrict size of page_cgroup->flags

[Daisuke Nishimura]

On Wed, 6 Oct 2010 19:53:14 +0530
Balbir Singh <balbir@linux.vnet.ibm.com> wrote:

> I propose restricting page_cgroup.flags to 16 bits. The patch for the
> same is below. Comments?
> 
> 
> Restrict the bits usage in page_cgroup.flags
> 
> From: Balbir Singh <balbir@linux.vnet.ibm.com>
> 
> Restricting the flags helps control growth of the flags unbound.
> Restriciting it to 16 bits gives us the possibility of merging
> cgroup id with flags (atomicity permitting) and saving a whole
> long word in page_cgroup
> 
I agree that reducing the size of page_cgroup would be good and important.
But, wouldn't it be better to remove ->page, if possible ?

Thanks,
Daisuke Nishimura.

> Signed-off-by: Balbir Singh <balbir@linux.vnet.ibm.com>
> ---
> 
>  include/linux/page_cgroup.h |    3 +++
>  mm/page_cgroup.c            |    1 +
>  2 files changed, 4 insertions(+), 0 deletions(-)
> 
> 
> diff --git a/include/linux/page_cgroup.h b/include/linux/page_cgroup.h
> index 872f6b1..10c37b4 100644
> --- a/include/linux/page_cgroup.h
> +++ b/include/linux/page_cgroup.h
> @@ -44,8 +44,11 @@ enum {
>  	PCG_FILE_WRITEBACK, /* page is under writeback */
>  	PCG_FILE_UNSTABLE_NFS, /* page is NFS unstable */
>  	PCG_MIGRATION, /* under page migration */
> +	PCG_MAX_NR,
>  };
>  
> +#define PCG_MAX_BIT_SIZE	16
> +
>  #define TESTPCGFLAG(uname, lname)			\
>  static inline int PageCgroup##uname(struct page_cgroup *pc)	\
>  	{ return test_bit(PCG_##lname, &pc->flags); }
> diff --git a/mm/page_cgroup.c b/mm/page_cgroup.c
> index 5bffada..e16ad2e 100644
> --- a/mm/page_cgroup.c
> +++ b/mm/page_cgroup.c
> @@ -258,6 +258,7 @@ void __init page_cgroup_init(void)
>  	unsigned long pfn;
>  	int fail = 0;
>  
> +	BUILD_BUG_ON(PCG_MAX_NR >= PCG_MAX_BIT_SIZE);
>  	if (mem_cgroup_disabled())
>  		return;
>  
> 
> -- 
> 	Three Cheers,
> 	Balbir
> 
> --
> 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>
> 

--
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>

Re: [RFC] Restrict size of page_cgroup->flags

[Balbir Singh]

* nishimura@mxp.nes.nec.co.jp <nishimura@mxp.nes.nec.co.jp> [2010-10-07 09:54:58]:

> On Wed, 6 Oct 2010 19:53:14 +0530
> Balbir Singh <balbir@linux.vnet.ibm.com> wrote:
> 
> > I propose restricting page_cgroup.flags to 16 bits. The patch for the
> > same is below. Comments?
> > 
> > 
> > Restrict the bits usage in page_cgroup.flags
> > 
> > From: Balbir Singh <balbir@linux.vnet.ibm.com>
> > 
> > Restricting the flags helps control growth of the flags unbound.
> > Restriciting it to 16 bits gives us the possibility of merging
> > cgroup id with flags (atomicity permitting) and saving a whole
> > long word in page_cgroup
> > 
> I agree that reducing the size of page_cgroup would be good and important.
> But, wouldn't it be better to remove ->page, if possible ?
>

Without the page pointer, how do we go from pc to page for reclaim? 

-- 
	Three Cheers,
	Balbir

--
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>

Re: [RFC] Restrict size of page_cgroup->flags

[Daisuke Nishimura]

On Thu, 7 Oct 2010 08:44:59 +0530
Balbir Singh <balbir@linux.vnet.ibm.com> wrote:

> * nishimura@mxp.nes.nec.co.jp <nishimura@mxp.nes.nec.co.jp> [2010-10-07 09:54:58]:
> 
> > On Wed, 6 Oct 2010 19:53:14 +0530
> > Balbir Singh <balbir@linux.vnet.ibm.com> wrote:
> > 
> > > I propose restricting page_cgroup.flags to 16 bits. The patch for the
> > > same is below. Comments?
> > > 
> > > 
> > > Restrict the bits usage in page_cgroup.flags
> > > 
> > > From: Balbir Singh <balbir@linux.vnet.ibm.com>
> > > 
> > > Restricting the flags helps control growth of the flags unbound.
> > > Restriciting it to 16 bits gives us the possibility of merging
> > > cgroup id with flags (atomicity permitting) and saving a whole
> > > long word in page_cgroup
> > > 
> > I agree that reducing the size of page_cgroup would be good and important.
> > But, wouldn't it be better to remove ->page, if possible ?
> >
> 
> Without the page pointer, how do we go from pc to page for reclaim? 
> 
We store page_cgroups in arrays now, so I suppose we can implement pc_to_pfn()
using the similar calculation as page_to_pfn() does.
IIRC, KAMEZAWA-san talked about it in another thread.

Thanks,
Daisuke Nishimura.

--
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>

Re: [RFC] Restrict size of page_cgroup->flags

[Balbir Singh]

* nishimura@mxp.nes.nec.co.jp <nishimura@mxp.nes.nec.co.jp> [2010-10-07 12:47:06]:

> On Thu, 7 Oct 2010 08:44:59 +0530
> Balbir Singh <balbir@linux.vnet.ibm.com> wrote:
> 
> > * nishimura@mxp.nes.nec.co.jp <nishimura@mxp.nes.nec.co.jp> [2010-10-07 09:54:58]:
> > 
> > > On Wed, 6 Oct 2010 19:53:14 +0530
> > > Balbir Singh <balbir@linux.vnet.ibm.com> wrote:
> > > 
> > > > I propose restricting page_cgroup.flags to 16 bits. The patch for the
> > > > same is below. Comments?
> > > > 
> > > > 
> > > > Restrict the bits usage in page_cgroup.flags
> > > > 
> > > > From: Balbir Singh <balbir@linux.vnet.ibm.com>
> > > > 
> > > > Restricting the flags helps control growth of the flags unbound.
> > > > Restriciting it to 16 bits gives us the possibility of merging
> > > > cgroup id with flags (atomicity permitting) and saving a whole
> > > > long word in page_cgroup
> > > > 
> > > I agree that reducing the size of page_cgroup would be good and important.
> > > But, wouldn't it be better to remove ->page, if possible ?
> > >
> > 
> > Without the page pointer, how do we go from pc to page for reclaim? 
> > 
> We store page_cgroups in arrays now, so I suppose we can implement pc_to_pfn()
> using the similar calculation as page_to_pfn() does.
> IIRC, KAMEZAWA-san talked about it in another thread.
>

Yes, correct we do. Your suggestions, IIUC is to reuse part of the
flags to store the section number where the pc belongs and then use
that to remove ->page pointer.

-- 
	Three Cheers,
	Balbir

--
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>