Re: [PATCH, v7] cgroups: introduce timer slack controller

[Thomas Gleixner]

On Wed, 2 Mar 2011, Matt Helsley wrote:

> On Wed, Mar 02, 2011 at 07:40:01PM +0100, Thomas Gleixner wrote:
> > On Wed, 2 Mar 2011, Kirill A. Shutsemov wrote:
> 
> <snip>
> 
> > > +		if (val > child->min_slack_ns)
> > > +			tslack_write_min(cur, cft, val);
> > > +	}
> > 
> > So, we can increase the value and propagate it through the groups
> > children, but decreasing it requires to go through all child groups
> > seperately. 
> 
> One goal is to restrict shrinking timer slacks so that they
> cannot be less than the parent cgroup's.

Right, but that's not what the code is doing.
 
> > 
> > When I'm trying to optimize something during runtime and chose a too
> > high value I need to go through hoops and loops to make it smaller
> > again.
> > 
> > Asymetric behaviour sucks always.
> 
> Well, in this case I think the asymmetry is less sucky because I don't
> see any point in imposing the same restrictions on raising the timer
> slack *except* this symmetry argument. But I haven't played much with
> timer slacks so I don't know: Is there any case where raising the timer
> slack would be harmful?

Well, the slack can delay your timer expiry by slack ns. So chosing a
too large slack value can affect the functionality of an application.

Now imagine you are tuning your system and typo the slack value by an
order of magnitude, which makes your apps unhappy. Then you definitely
want to be able to undo that w/o going through loops and circles.

> Would making the values additive solve the symmetry problem? In other words,
> the "minimum" you see in a cgroups min_slack_ns file is the minimum in
> addition to the minimum timer slack of its parent. Then, so long as negative
> values are disallowed, you can't possibly write values that violate this
> restriction. We could re-evaluate the resulting minimum timer slack internally
> during writes to the file so functions using timer slack won't have to walk
> the cgroup parents to calculate it but it couldn't result in EPERM...

That would work, but that wants some interface to read out the
effective slack value for a group.

Thanks,

	tglx
--
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/