Quoting Jäkel, Guido (g.jae...@dnb.de): > Dear Core-Developers, > > i would like to ask for a discussion about the status of a kind of > improvements that -- as I know -- will need support by the kernel developers. > But a LXC (newbie) user may expect such things from a software level 1.0, > will miss it. In the worst case, this may have impacts on the image of LXC > because one may think it's in the direct concern of LXC to provide it. > > As an example, the cgroups framework offers the (functional) resource > limiters for memory and CPU. But for a process within such a group -- here: a > container -- there's no adequate projection on the common used interfaces by > all the software around: It will determine the memory resources or total > number of CPUs of the host. Therefore the user have manually adjust it - if > he knows about the fact and the software offer the possibility to override it. > > Is there any ongoing work on this by kernel developers? May there be notable > improvements within the timeline of the LXC 1.0 release?
No ongoing work right now or on the 1.0 roadmap iirc. The previously considered possible options, in decreasing order of likelyhood to be acceptable, are: 1. Implement a new library which provides memory and cpu usage, etc. Move userspace to using those instead of procfiles. 2. Implement a procfs to provide virtualized views of memory and cpu usage, etc, and integrate it nicely with lxc. Daniel had started this years ago, but the last codedrop which I found of this is pretty badly out of date, so easiest would be to start from scratch. Note noone in kernel-land or other packages would need to get involved. So in a sense this is more likely than (1) to be acceptable - but it's not as desirable. The reason is that as procfiles and cgroup behavior change, instead of one library needing updates, every project's own procfs will need to be maintained. It might therefore be worthwhile to have a few interested people work together on an independent such project. (note that libvirt has a procfs which is virtualizing exactly one procfile) In that sense this would just be (1) moved down a level. 3. Implement filtering of procfiles right in the kernel's procfs code. In the past that has been rejected, but then preferred kernel aesthetics do change (somewhat in cycles) so it's always possible that, if you do it right, you could succeed. -serge ------------------------------------------------------------------------------ See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk _______________________________________________ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
