On 01/10/2013 01:27 AM, Glauber Costa wrote: > On 01/10/2013 01:17 AM, Andrew Morton wrote: >> On Thu, 10 Jan 2013 01:10:02 +0400 >> Glauber Costa <glommer@xxxxxxxxxxxxx> wrote: >> >>> 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. > Andrew, Given my arguments above, which interface would you prefer for me to settle down? I still don't see any problems with the header, specially given the fact that it exists precisely to allow fields to come and go if needed. -- To unsubscribe from this list: send the line "unsubscribe cgroups" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
