Currently, /proc/cgroups outputs is fairly ugly as following,
#subsys_name hierarchy num_cgroups enabled
cpuset 0 1 1
debug 0 1 1
ns 0 1 1
indent it in a good-looking way.
#subsys_name hierarchy num_cgroups enabled
cpuset 0 1 1
debug 0 1 1
ns 0 1 1
Signed-off-by: Gui Jianfeng <[email protected]>
---
kernel/cgroup.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index 3737a68..99fc160 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -2963,7 +2963,7 @@ static int proc_cgroupstats_show(struct seq_file *m, void *v)
mutex_lock(&cgroup_mutex);
for (i = 0; i < CGROUP_SUBSYS_COUNT; i++) {
struct cgroup_subsys *ss = subsys[i];
- seq_printf(m, "%s\t%lu\t%d\t%d\n",
+ seq_printf(m, "%s\t\t%lu\t\t%d\t\t%d\n",
ss->name, ss->root->subsys_bits,
ss->root->number_of_cgroups, !ss->disabled);
}
--
1.5.4.rc3
CC: container list
Gui Jianfeng wrote:
> Currently, /proc/cgroups outputs is fairly ugly as following,
> #subsys_name hierarchy num_cgroups enabled
> cpuset 0 1 1
> debug 0 1 1
> ns 0 1 1
>
> indent it in a good-looking way.
> #subsys_name hierarchy num_cgroups enabled
> cpuset 0 1 1
> debug 0 1 1
> ns 0 1 1
>
But if there's a subsystem with name length >= 8,
it won't be aligned properly..
>
> Signed-off-by: Gui Jianfeng <[email protected]>
> ---
> kernel/cgroup.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/kernel/cgroup.c b/kernel/cgroup.c
> index 3737a68..99fc160 100644
> --- a/kernel/cgroup.c
> +++ b/kernel/cgroup.c
> @@ -2963,7 +2963,7 @@ static int proc_cgroupstats_show(struct seq_file *m, void *v)
> mutex_lock(&cgroup_mutex);
> for (i = 0; i < CGROUP_SUBSYS_COUNT; i++) {
> struct cgroup_subsys *ss = subsys[i];
> - seq_printf(m, "%s\t%lu\t%d\t%d\n",
> + seq_printf(m, "%s\t\t%lu\t\t%d\t\t%d\n",
> ss->name, ss->root->subsys_bits,
> ss->root->number_of_cgroups, !ss->disabled);
> }
Li Zefan wrote:
> CC: container list
>
> Gui Jianfeng wrote:
>> Currently, /proc/cgroups outputs is fairly ugly as following,
>> #subsys_name hierarchy num_cgroups enabled
>> cpuset 0 1 1
>> debug 0 1 1
>> ns 0 1 1
>>
>> indent it in a good-looking way.
>> #subsys_name hierarchy num_cgroups enabled
>> cpuset 0 1 1
>> debug 0 1 1
>> ns 0 1 1
>>
>
> But if there's a subsystem with name length >= 8,
> it won't be aligned properly..
Yeap, but there isn't such a case at least by now.
>
>> Signed-off-by: Gui Jianfeng <[email protected]>
>> ---
>> kernel/cgroup.c | 2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/kernel/cgroup.c b/kernel/cgroup.c
>> index 3737a68..99fc160 100644
>> --- a/kernel/cgroup.c
>> +++ b/kernel/cgroup.c
>> @@ -2963,7 +2963,7 @@ static int proc_cgroupstats_show(struct seq_file *m, void *v)
>> mutex_lock(&cgroup_mutex);
>> for (i = 0; i < CGROUP_SUBSYS_COUNT; i++) {
>> struct cgroup_subsys *ss = subsys[i];
>> - seq_printf(m, "%s\t%lu\t%d\t%d\n",
>> + seq_printf(m, "%s\t\t%lu\t\t%d\t\t%d\n",
>> ss->name, ss->root->subsys_bits,
>> ss->root->number_of_cgroups, !ss->disabled);
>> }
>
>
>
>
--
Regards
Gui Jianfeng
Gui Jianfeng wrote:
> Li Zefan wrote:
>> CC: container list
>>
>> Gui Jianfeng wrote:
>>> Currently, /proc/cgroups outputs is fairly ugly as following,
>>> #subsys_name hierarchy num_cgroups enabled
>>> cpuset 0 1 1
>>> debug 0 1 1
>>> ns 0 1 1
>>>
>>> indent it in a good-looking way.
>>> #subsys_name hierarchy num_cgroups enabled
>>> cpuset 0 1 1
>>> debug 0 1 1
>>> ns 0 1 1
>>>
>> But if there's a subsystem with name length >= 8,
>> it won't be aligned properly..
>
> Yeap, but there isn't such a case at least by now.
>
This is not a good reason.
We'll probably have such a subsystem. Actually there's a
proposed subsystem named "maxdepth" which is of length 8.
See:
http://lkml.org/lkml/2009/7/1/581
Li Zefan wrote:
> Gui Jianfeng wrote:
>> Li Zefan wrote:
>>> CC: container list
>>>
>>> Gui Jianfeng wrote:
>>>> Currently, /proc/cgroups outputs is fairly ugly as following,
>>>> #subsys_name hierarchy num_cgroups enabled
>>>> cpuset 0 1 1
>>>> debug 0 1 1
>>>> ns 0 1 1
>>>>
>>>> indent it in a good-looking way.
>>>> #subsys_name hierarchy num_cgroups enabled
>>>> cpuset 0 1 1
>>>> debug 0 1 1
>>>> ns 0 1 1
>>>>
>>> But if there's a subsystem with name length >= 8,
>>> it won't be aligned properly..
>> Yeap, but there isn't such a case at least by now.
>>
>
> This is not a good reason.
>
> We'll probably have such a subsystem. Actually there's a
> proposed subsystem named "maxdepth" which is of length 8.
>
> See:
> http://lkml.org/lkml/2009/7/1/581
yes, this is a case. But at least others can be aligned
properly, right? Anyway, please ignore it if you don't
like this change.
>
>
>
>
--
Regards
Gui Jianfeng
On Fri, Jul 3, 2009 at 1:05 AM, Gui Jianfeng<[email protected]> wrote:
> Currently, /proc/cgroups outputs is fairly ugly as following,
Yes, I agree it's somewhat ugly. But it's at least very easily machine
parseable, and fairly easily human parseable, which are the important
points.
Paul