Re: [LSF/MM TOPIC] memory control groups

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

On Tue, 18 Jan 2011 09:40:13 +0100
Johannes Weiner <hannes@cmpxchg.org> wrote:

> On Tue, Jan 18, 2011 at 10:10:57AM +0900, KAMEZAWA Hiroyuki wrote:
> > On Mon, 17 Jan 2011 20:14:00 +0100
> > Johannes Weiner <hannes@cmpxchg.org> wrote:

> > - pc->mem_cgroup can be replaced with ID.
> >   But move it into flags field seems difficult because of races.
> > - pc->page can be replaced with some lookup routine.
> >   But Section bit encoding may be something mysterious and look up cost
> >   will be problem.
> 
> Why is that?
> 
> The lookup is actually straight-forward, like lookup_page_cgroup().
> And we only need it when coming from the per-cgroup LRU, i.e. in
> reclaim and force_empty.
>  

I see usage of pc->page is not very frequent. But I wonder we should
revisit performance of lookup_page_cgroup() before adding new weight.


> > - PCG_CACHE bit is a duplicate of information of 'page'. So, we can use PageAnon()
> 
> I did that, too.  But for this to work, we need to make sure that
> pages are always rmapped when they are charged and uncharged.  This is
> one point where I collide with THP.  It's also why I complained that
> migration clears page->mapping of replaced anonymous pages :)
> 
> > - 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.


> > 
> > Another idea is dynamic allocation of page_cgroup. It may be able to be a help
> > for THP enviroment but will not work well (just adds overhead) against file cache
> > workload.
> > 
> > Anwyay, my priority of development for memcg this year is:
> > 
> >  1. dirty ratio support.
> >  2. Backgound reclaim (kswapd)
> >  3. blkio tracking.
> > 
> > Diet of page_cgroup should be done in step by step. We've seen many level down
> > when some new feature comes to memory cgroup.
> 
> Yes, and that's what I'm afraid of.  We would never be able to add a
> side-feature that makes struct page increase in arbitrary size.
> 
> If the feature is sufficiently important and there is no other way, it
> should of course be an option.  But it should not be done careless.
> 
> 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.
> 
> But yes, that's sort of what I want to discuss :)
> 

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.

Anyway, if the kernel goes to merge IO-less page reclaim, dirty ratio
support is the 1st thing we have to implement.
Without that, memcg will easily OOM.

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>