I found that /proc/cgroups printed format has ugly alignment(see below).
This patch confines every field in fixed-width(16 actually) range.
Though MAX_CGROUP_TYPE_NAMELEN is 32, but currently no subsystem
has name width more than 10, so 16 is a moderate width; besides, 16
figures could accomandate enormous huge number, so no need to worry
that these fields would clobber each other.
Before:
#subsys_name hierarchy num_cgroups enabled
cpuset 2 1 1
cpu 3 1 1
cpuacct 3 1 1
memory 4 1 1
devices 5 1 1
freezer 6 1 1
net_cls 7 1 1
blkio 8 1 1
perf_event 9 1 1
hugetlb 10 1 1
Patch applied:
#subsys_name hierarchy num_cgroups enabled
cpuset 2 1 1
cpu 3 1 1
cpuacct 3 1 1
memory 4 1 1
devices 5 1 1
freezer 6 1 1
net_cls 7 1 1
blkio 8 1 1
perf_event 9 1 1
hugetlb 10 1 1
Signed-off-by: Jianyu Zhan <[email protected]>
---
kernel/cgroup.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index 9fcdaa7..d981697 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -4347,7 +4347,7 @@ static int proc_cgroupstats_show(struct seq_file *m, void *v)
mutex_lock(&cgroup_mutex);
for_each_subsys(ss, i)
- seq_printf(m, "%s\t%d\t%d\t%d\n",
+ seq_printf(m, "%-16s%-16d%-16d%-16d\n",
ss->name, ss->root->hierarchy_id,
atomic_read(&ss->root->nr_cgrps), !ss->disabled);
--
1.9.0.GIT
On Tue, Apr 15, 2014 at 08:47:45PM +0800, Jianyu Zhan wrote:
> I found that /proc/cgroups printed format has ugly alignment(see below).
>
> This patch confines every field in fixed-width(16 actually) range.
> Though MAX_CGROUP_TYPE_NAMELEN is 32, but currently no subsystem
> has name width more than 10, so 16 is a moderate width; besides, 16
> figures could accomandate enormous huge number, so no need to worry
> that these fields would clobber each other.
The problem there is that there could be programs / scripts parsing it
assuming single tab between entries. It surely is ugly but do we
care?
Thanks.
--
tejun
On Tue, Apr 15, 2014 at 08:47:45PM +0800, Jianyu Zhan wrote:
> I found that /proc/cgroups printed format has ugly alignment(see below).
[snip]
> diff --git a/kernel/cgroup.c b/kernel/cgroup.c
> index 9fcdaa7..d981697 100644
> --- a/kernel/cgroup.c
> +++ b/kernel/cgroup.c
> @@ -4347,7 +4347,7 @@ static int proc_cgroupstats_show(struct seq_file *m, void *v)
> mutex_lock(&cgroup_mutex);
>
> for_each_subsys(ss, i)
> - seq_printf(m, "%s\t%d\t%d\t%d\n",
> + seq_printf(m, "%-16s%-16d%-16d%-16d\n",
> ss->name, ss->root->hierarchy_id,
> atomic_read(&ss->root->nr_cgrps), !ss->disabled);
This is liable to break userspace apps which might currently parse the
file by splitting on '\t'
Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
On Tue, Apr 15, 2014 at 8:51 PM, Tejun Heo <[email protected]> wrote:
> The problem there is that there could be programs / scripts parsing it
> assuming single tab between entries. It surely is ugly but do we
> care?
Oh, you are right. It is an exposed user interface. This will make lots of
administrator unhappy ;-(
Thanks,
Jianyu Zhan