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. -- 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
