Re: [libvirt] [PATCH v2] lxc: fuse mount for /proc/cpuinfo

On Mon, Sep 07, 2015 at 03:39:13PM +0000, Serge Hallyn wrote: > Quoting Daniel P. Berrange (berrange(a)redhat.com): > > On Thu, Sep 03, 2015 at 11:51:16AM +0200, Cédric Bosdonnat wrote: > > > We already have a fuse mount to reflect the cgroup memory restrictions > > > in the container. This commit adds the same for the number of available > > > CPUs. Only the CPUs listed by virProcessGetAffinity are shown in the > > > container's cpuinfo. > > > > So this (re-)raises some interesting / difficult questions that I'm > > not sure we have a good answer to. > > > > The main concern is that actually this is not really a problem specific > > to containers, rather it is related to cgroup resource confinement. > > ie the cgroup has confined a process(es) to a set of CPUs are the process > > is using /proc/cpuinfo to count CPUs and so is wrong. Cgroups are being > > increasingly widely used in Linux, particularly since systemd, so pretty > > much any process has to expect that it can be confined to a subset of > > CPUs. > > > > IOW, any application using /proc/cpuinfo to determine "available" > > resource is already broken, even when run on bare metal. The same also > > applies to the use of /proc/meminfo, which we previously faked via > > fuse. > > > > So the question is whether we should invest time trying to fake the > > /proc/cpuinfo in containers, when any apps we'd be fixing are already > > broken in bare metal. Apps might have avoided /proc/cpuinfo and instead > > be trying /sys/devices/system/cpu/ which your patch isn't trying to > > fake. This is just as broken, because sysfs doesn't reflect cgroup > > confinement either. > > > > I think what is ultimately needed for applications is some kind of > > libresource.so library that they can use to query what resources > > Does anyone remember who it was that announced an effort to this > end a year or two ago, or know what the status of it is? I don't recall seeing any formal announcement about this, but I have had this exact same discussion with Red Hat folks involved with Docker and similar higher level container mgmt tools, so perhaps someone involved in those efforts is working on it ?