Date:	Thu, 12 Apr 2012 10:41:55 -0700
From:	Tejun Heo <tj@...nel.org>
To:	Johannes Weiner <hannes@...xchg.org>
Cc:	Glauber Costa <glommer@...allels.com>,
	Frederic Weisbecker <fweisbec@...il.com>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
	Hugh Dickins <hughd@...gle.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Daniel Walsh <dwalsh@...hat.com>,
	"Daniel P. Berrange" <berrange@...hat.com>,
	Li Zefan <lizf@...fujitsu.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Cgroups <cgroups@...r.kernel.org>,
	Containers <containers@...ts.linux-foundation.org>
Subject: Re: [RFD] Merge task counter into memcg

Hello, Johannes.

On Thu, Apr 12, 2012 at 07:23:09PM +0200, Johannes Weiner wrote:
> > The task counter is trying to control the *number* of tasks, which is
> > purely memory overhead.  Translating #tasks into the actual amount of
> > memory isn't too trivial tho - the task stack isn't the only
> > allocation and the numbers should somehow make sense to the userland
> > in consistent way.
> 
> But why would you ever even care about that number, though?  It has no
> intrinsic value.  We used it in a past because we had no other control
> over kernel memory and CPU usage.

I was describing task_counter as implemented mostly to point out that
it's not cpu related.  It's fundamentally a memory overhead which is
coarsely / impreciesly mapped to some number, so umm... we're actually
agreeing.

> Even if we start out accounting just the kernel stack (which should be
> the biggest chunk), it won't be less accurate than limiting numbers of
> tasks.  It's just a different unit, but one which we can account and
> limit with less extra code, and even improve as we go along.
> 
> [ You could have tuned your task counter limit perfectly to one kernel
>   version, the next version will have changed the memory required per
>   task, file, random object, and suddenly your working setup runs out
>   of memory.  So it's not like starting with kernel stack and adding
>   more stuff later would be any less predictable. ]
> 
> I don't think anyone wants to come back in a few months and discuss
> where the nr-of-open-files counter subsystem should live.
>
> > Also, I'm not sure whether this particular limit should live in its
> > silo or should be summed up together as part of kmem (kmem itself is
> > in its own silo after all apart from user memory, right?).
> 
> There is k and u+k.  I don't see a technical problem with adding a
> separate stat for it later, but also not a particular reason to treat
> it differently, because it's nothing special.  It's just kernel
> memory.  Do you care if your cgroup has 2M tasks with one open socket
> each or one task with 2M sockets, as long as the group plays along
> nicely with the others?

I'm still split on the issue.

* #tasks as unit of accounting / limiting is well understood (or at
  least known).  I think this holds the same to #open files, to a
  lesser extent.  It means there are and will continue to be people
  wanting them.  So, they have some value in familiarity - "but... I
  want to limit the resources consumed by tasks cuz that's what I
  know!" factor.

* People could want counting and limiting #tasks or #open files
  without the overhead of tracking all memory resources.  This stems
  from the same reason #tasks was used for this sort of things in the
  first place.  Counting tasks or open files tends to be easier and
  cheaper than tracking all memory allocations.

So, there's spectrum of solutions between merging task counter and
just directing everyone to kmem without distinguishing task resource
at all, and at the moment voices in my head are succeeding at making
cases for both directions.  What do you guys think about the above two
issues?

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists