On 01/10/2013 01:17 AM, Andrew Morton wrote:

On Thu, 10 Jan 2013 01:10:02 +0400
Glauber Costa [off-list ref] wrote:

quoted

The main advantage I see in this approach, is that there is way less
data to be written using a header. Although your way works, it means we
will write the strings "nice", "system", etc. #cpu times. Quite a waste.

Yes, overhead can be a significant issue with this type of interface. 
But we already incurred a massive overhead by using a human-readable
ascii interface.  If performance is an issue, perhaps the whole thing
should be grafted onto taskstats instead.  Or create a new
taskstats-like thing.

I think this would be a little alienish in the already alien world of
cgroups.

However, I was not so much talking about plain performance overhead as
measurable in miliseconds-to-parse, but rather just alluding to the fact
that we would be writing the same set of strings multiple times when a
header would do just fine.

This is the same method used for instance by slabinfo.

btw, a more typical interface would be

cat /.../cpu0
nice:nn
system:nn
irq:nn

Well, yes. But welcome to cgroups: directories have a meaning, so the
only way to organize stuff is with plain files in the current hierarchy
is by filling it with files. As many files as we have cpus.

At this point you are certain to miss all the other files present in the
directory.

- the traditional one-per-line name:value tuples.  But I'd assumed that
having a file per CPU would be aawkward.

Indeed.