Re: [LSF/MM TOPIC] memory control groups

[KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>]

On Tue, 18 Jan 2011 11:20:06 +0100
Johannes Weiner <hannes@cmpxchg.org> wrote:

> On Tue, Jan 18, 2011 at 06:17:57PM +0900, KAMEZAWA Hiroyuki wrote: 
> > > > - I'm not sure PCG_MIGRATION. It's for avoiding races.
> > > 
> > > That's also a scary patch...  Yeah, it's to prevent uncharging of
> > > oldpage in case migration fails and it has to be reused.  I changed
> > > the migration sequence for memcg a bit so that we don't have to do
> > > that anymore.  It survived basic testing.
> > > 
> > 
> > Hmm. I saw level down of migration under memcg several times. So, I don't
> > want to modify running one without enough reason.
> > I guess all SECTION_BITS can be encoded to pc->flags without diet of flags.
> 
> That's true, there is enough room for that.
> 
> Those reduction patches I only wrote to also pack the pc->mem_cgroup
> ID into pc->flags, but these are two independent problems.
> 

That packing is dangerous because we have lock bit on pc->flags and
some access to pc->mem_cgroup is lockless. IIUC, it's difficult to
avoid race with modifying pc->mem_cgroup.
Hm, if we remove PCG_ACCT_LRU, it may be possible but I'm not sure
how FILESTAT etc. is safe.


> I would not have finished the patch only for that one tiny flag, but
> it actually saved code and made it IMO a bit easier to understand.  I
> consider this a serious upside of code that has a history of breaking.
> 
> But one at the time, first I will finish testing and benchmarking the
> pc->page removal.
> 
Sure.

> > > E.g. I have a suspicion that we might be able to do dirty accounting
> > > without all the flags (we have them in the page anyway!) but use
> > > proportionals instead.  It's not page-accurate, but I think the
> > > fundamental problem is solved: when the dirty ratio is exceeded,
> > > throttle the cgroup with the biggest dirty share.
> > 
> > Using proportionals is a choice. But, IIUC, users of memcg wants 
> > something like /proc/meminfo. It doesn't match.
> > If I'm an user of container, I want an information like /proc/meminfo for
> > container.
> 
> I totally agree that this is information that needs exporting.
> 
> But you can easily calculate an absolute number of bytes by applying a
> memcg's relative proportion to the absolute amount of dirty pages for
> example.  The only difference is that it probably won't be 100%
> accurate, but a few pages difference should really not matter for
> user-visible statistics.
> 
> No?
> 
With proportionals, we can't handle account moving between cgroups.
That means rmdir, force_empty, task_move can break dirty statistics
into mess.

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/ .
Fight unfair telecom policy in Canada: sign http://dissolvethecrtc.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>