[lxc-devel] cgroup management daemon

[Tim Hockin]

On Tue, Nov 26, 2013 at 8:12 AM, Serge E. Hallyn <serge at hallyn.com> wrote:
> Quoting Tim Hockin (thockin at google.com):
>> What are the requirements/goals around performance and concurrency?
>> Do you expect this to be a single-threaded thing, or can we handle
>> some number of concurrent operations?  Do you expect to use threads of
>> processes?
>
> The cgmanager should be pretty dumb, so I would expect it to be
> quite fast.  I don't have any specific perf goals though.  If you
> have requirements I'm very interested to hear them.  I should be
> able to tell pretty soon how far short I fall.

If we're limiting this to write traffic only, I think our perf goals
are fairly relaxed.  As longs as you don't develop it to preclude
threading or multi-processing, we can adapt later.  I would like to
see at least a mention to this effect.  We also need to beware DoS
(accidental or otherwise) - perhaps we should force round-robin
service of pending-requests, or something.

> By default I'd expect to run with a single thread, but I don't
> imagine one thread can serve a busy 1024-cpu system very well.
> Unless you have guidance right now, I think I'd like to get
> started with the basic functionality and see how it measures
> up to your requirements.  I should add perf counters from the
> start so we can figure out where bottlenecks (if any) are and
> how to handle them.
>
> Otherwise I could start out with a basic numcpus/10 threadpool
> and have the main thread do socket i/o and parcel access
> verification and vfs work out to the threadpool, but I'd rather
> first know where the problems lie.

Agree.  Correct first, then fast :)

>> Can you talk about logging - what and where?
>
> When started under upstart, anything we print out goes to
> /var/log/upstart/cgmanager.log.  Would be nice to keep it
> that simple.  We could log requests by r to do something
> it is not allowed to do, but it seems to me the failed
> attempts cause no harm, while the potential for overflowing
> logs can.

I agree that we don't want to overflow logs.

> Did you have anything in mind?  Did you want logging to help
> detect certain conditions for system optimization, or just
> for failure notices and security violations?

When something goes amiss, we have to ty to figure out what happened -
how far did a request get?  Logging every change is probably
important.  Logging failures could be downsampled and rate-limited,
something like 1 failure log per second or something.

>> How will we handle event_fd?  Pass a file-descriptor back to the caller?
>
> The only thing currently supporting eventfd is memory threshold,
> right?  I haven't tested whether this will work or not, but
> ideally the caller would open the eventfd fd, pass it, the
> cgroup name, controller file to be watched, and the args to
> cgmanager;  cgmanager confirms read access, opens the
> controller fd, makes the request over cgroup.event_control,
> then passes the controller fd back to the caller and closes
> its own copy.
>
> I'm also not sure whether the cgroup interface is going to be
> offering a new feature to replace eventfd, since it wants
> people to stop using cgroupfs...  Tejun?
>
>> That's all I can come up with for now.