-----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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iEYEARECAAYFAlXnaHQACgkQ0Bme0QyNhPRupgCgysVF6ggmb4iq/RNoX+2I5P8Z
sMwAn1ZocxaAD3DtYe37giD0KAejaZmi
=zWbT
-----END PGP SIGNATURE-----