[PATCH 07/12] cgroup: unify cgroup_write_X64() and cgroup_write_string()

Michal Hocko mhocko at suse.cz
Mon Dec 2 14:12:42 UTC 2013


On Mon 02-12-13 08:30:59, Tejun Heo wrote:
> Hello, Michal.
> 
> On Mon, Dec 02, 2013 at 10:54:01AM +0100, Michal Hocko wrote:
> > Well, I am not happy about the use case as well and I will always
> > discourage people from doing this. I was merely pointing out that the
> > patch will break those even though it seems trivial to not do so. That
> > being said I would rather see no allocation in that path but if that
> > doesn't seem viable to you then I will not loose any sleep over it.
> 
> So, is it something already working reliably?  I really don't like the
> implications of heading this way.  Does it also mean cgroup won't be
> able to use seq_file for read paths either?

One has to try hard but I guess this is doable. At least as simple
things as try to enlarge the limit approach should be easy to do.

> We're talking about a *lot* of extra restrictions and shackles if we
> go down this path and many of them would be extremely subtle and
> fragile. If this is an one-off thing to keep the existing users
> happy, I'm okay with it and will update this patch and kernfs so that
> writes under certain size use on-stack buffer, but I *DO* want an
> assurance that memcg isn't gonna march that way, which is likely to
> bring down the rest of cgroup in the process.

I really do not want to add more hacks just to make this use case work.
There are some proposals for more systematic implementation (memory
reserves for oom killer etc.) but that won't interfere with the cgroup
core.
This one just looks trivial so I was thinking whether we can keep the
!allocating write as before. It is nothing I would insist on, though. So
I will leave the decision on you.

> Well, either that or please convince me it's something sane to
> support, but you don't sound too sure either, so....
> 
> Thanks.
> 
> -- 
> tejun

-- 
Michal Hocko
SUSE Labs


More information about the Containers mailing list