On Tue, Nov 26, 2013 at 8:12 AM, Serge E. Hallyn <serge@xxxxxxxxxx> wrote: > Quoting Tim Hockin (thockin@xxxxxxxxxx): >> 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. -- To unsubscribe from this list: send the line "unsubscribe cgroups" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
