-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 09/02/2015 03:20 PM, Arnaldo Carvalho de Melo wrote:
Em Wed, Sep 02, 2015 at 02:24:56PM -0500, Guy Streeter escreveu:
I've been looking at the current "process view" frame in tuna. Can someone explain to me what the value of the "cgroups" column is?
I admit I don't understand cgroups very well, but the displayed information doesn't seem useful. Is there something more or different we could display there?
Yeah, I think someone involved with cgroups could try to make that more compact somehow, but indeed, I find that column not that useful.
What would an administrator do with the current cgroups information? Should we consider adding cgroups configuration/administration to tuna, or is there already a GUI for that?
I am not sure about that, i.e. about any adminstrative tool for that.
What I think would be useful would be for the _command line_ to be able to, in addition to --socket, --cpu, --thread, --irq to also have support for --cgroup.
I've written Python bindings for libcgroup: https://git.fedorahosted.org/cgit/python-libcgroup.git/
In the GUI, I think cgroups, at least the cpuset part, could be thought of as a "soft CPU socket", i.e. one that is not "written in stone", but in the kernel cgroup filesystem, i.e. for each cgroup we would have some box, showing which CPUs are in it, and also if one selected one of these boxes, then the thread view would show just the ones in that box (CPU socket, CPU core, cgroup).
...
But I haven't been following how all this plays with systemd, that makes heavy use of cgroups, etc. Would this be done directly via looking at the cgroups FS? Or would we use something else, like some dbus systemd service that would enumerate/create/delete/other-operations cgroups, etc?
- Arnaldo
On systems with systemd running, every process has a cgroup list at least this long:
$ cat /proc/self/cgroup 10:hugetlb:/ 9:perf_event:/ 8:net_cls,net_prio:/ 7:freezer:/ 6:devices:/user.slice 5:memory:/ 4:blkio:/ 3:cpu,cpuacct:/ 2:cpuset:/ 1:name=systemd:/user.slice/user-5160.slice/session-1.scope
Services have an even longer list. None of it means anything to me :)
In the long run, letting systemd handle cgroups is probably the right thing to do. There needs to be centralized control of them. There is a published systemd dbus interface for cgroups, but I can't tell if it is proposed or actually implemented.
As an aside, I haven't seen any evidence that systemd uses cgroups for CPU Affinity. I tried modifying the unit file for a service on my system, specifying the CPUAffinity property. systemd started the service with the specified affinity, but I think it just used taskset or sched_setaffinity. I could not see a cgroups change that limited the affinity, and I was able to change the affinity with tuna.
- --Guy