These patches add a new cgroup control file output type - a map from
strings to u64 values - and make use of it for the memory controller
"stat" file.
It is intended for use when the subsystem wants to return a collection
of values that are related in some way, for which a separate control
file for each value would make the reporting unwieldy.
The advantages of this are:
- more standardized output from control files that report
similarly-structured data
- less boilerplate required in cgroup subsystems
- simplifies transition to a future efficient cgroups binary API
Signed-off-by: Paul Menage <[email protected]>
--
> These patches add a new cgroup control file output type - a map from
> strings to u64 values - and make use of it for the memory controller
> "stat" file.
>
> It is intended for use when the subsystem wants to return a collection
> of values that are related in some way, for which a separate control
> file for each value would make the reporting unwieldy.
>
> The advantages of this are:
>
> - more standardized output from control files that report
> similarly-structured data
>
> - less boilerplate required in cgroup subsystems
>
> - simplifies transition to a future efficient cgroups binary API
>
> Signed-off-by: Paul Menage <[email protected]>
it changes the format from "%s %lld" to "%s: %llu", right?
why?
YAMAMOTO Takashi
On Feb 19, 2008 9:48 PM, YAMAMOTO Takashi <[email protected]> wrote:
>
> it changes the format from "%s %lld" to "%s: %llu", right?
> why?
>
The colon for consistency with maps in /proc. I think it also makes it
slightly more readable.
For %lld versus %llu - I think that cgroup resource APIs are much more
likely to need to report unsigned rather than signed values. In the
case of the memory.stat file, that's certainly the case.
But I guess there's an argument to be made that nothing's likely to
need the final 64th bit of an unsigned value, whereas the ability to
report negative numbers could potentially be useful for some cgroups.
Paul
> On Feb 19, 2008 9:48 PM, YAMAMOTO Takashi <[email protected]> wrote:
> >
> > it changes the format from "%s %lld" to "%s: %llu", right?
> > why?
> >
>
> The colon for consistency with maps in /proc. I think it also makes it
> slightly more readable.
can you be a little more specific?
i object against the colon because i want to use the same parser for
/proc/vmstat, which doesn't have colons.
btw, when making ABI changes like this, can you please mention it
explicitly in the patch descriptions?
> For %lld versus %llu - I think that cgroup resource APIs are much more
> likely to need to report unsigned rather than signed values. In the
> case of the memory.stat file, that's certainly the case.
>
> But I guess there's an argument to be made that nothing's likely to
> need the final 64th bit of an unsigned value, whereas the ability to
> report negative numbers could potentially be useful for some cgroups.
>
> Paul
i don't have any strong opinions about signedness.
YAMAMOTO Takashi
On Feb 19, 2008 10:14 PM, YAMAMOTO Takashi <[email protected]> wrote:
> > On Feb 19, 2008 9:48 PM, YAMAMOTO Takashi <[email protected]> wrote:
> > >
> > > it changes the format from "%s %lld" to "%s: %llu", right?
> > > why?
> > >
> >
> > The colon for consistency with maps in /proc. I think it also makes it
> > slightly more readable.
>
> can you be a little more specific?
>
> i object against the colon because i want to use the same parser for
> /proc/vmstat, which doesn't have colons.
Ah. This /proc behaviour of having multiple formats for reporting the
same kind of data (compare with /proc/meminfo, which does use colons)
is the kind of thing that I want to avoid with cgroups. i.e. if two
cgroup subsystems are both reporting the same kind of structured data,
then they should both use the same output format.
I guess since /proc has both styles, and memory.stat is the first file
reporting key/value pairs in cgroups, you get to call the format. OK,
I'll zap the colon.
Paul