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

[Balbir Singh]

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

> On Thu, 7 Oct 2010 08:42:04 +0530
> Balbir Singh <balbir@xxxxxxxxxxxxxxxxxx> wrote:
> 
> > * KAMEZAWA Hiroyuki <kamezawa.hiroyu@xxxxxxxxxxxxxx> [2010-10-07 08:58:58]:
> > 
> > > On Wed, 6 Oct 2010 19:53:14 +0530
> > > Balbir Singh <balbir@xxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxx>
> > > > 
> > > > 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@xxxxxxxxxxxxxxxxxx>
> > > 
> > > 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 from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/