Re: [PATCH] Performance Stats: Kernel patch

From: Balbir Singh
Date: Tue Jun 05 2007 - 02:56:40 EST


Andrew Morton wrote:
> On Wed, 30 May 2007 18:49:46 +0000
> Maxim Uvarov <muvarov@xxxxxxxxxxxxx> wrote:
>
>> +void print_taskstats(struct taskstats *t)
>> +{
>> + printf("\n\nTask %15s%15s\n"
>> + " %15lu%15lu\n",
>> + "voluntary", "nonvoluntary",
>> + t->nvcsw, t->nivcsw);
>> +}
>
> print_task_stats versus print_taskstats is a bit confusing, but I guess it
> doesn't matter.
>
> More significantly, the whole idea of calling it "task stats" isn't a good
> one: it's far too general. The whole kernel interface is called taskstats,
> but the additions here are a tiny part of that.
>
> Perhaps task_context_switch_rates would be more appropriate, although
> rather a lot to type.
>

I agree, taskstats is the name given to the genetlink interface.


> The patch otherwise seems OK. Thoughts:
>
> - Do we need to increment TASKSTATS_VERSION for this? I forget the rules
> there.

Any ABI change should result in a version bump. So the bump is ok

>
> - The lack of context-switch accounting in taskstats is, I think, a
> simple oversight. It should have been included on day one.
>

Yes, it should have been included

> There are perhaps other things which _should_ be in taskstats, but we
> forgot to add them. Can we think of any such things?
>

I think it's worth reviewing the data exported. I thought CSA filled
out the gaps, but it's definitely worth revisiting.


> We shouldn't just toss any old random stuff in there: it should be
> things which make sense, and which Unix or Linux accounting traditionally
> provides, and it should be something which we expect won't suddenly
> become unsupportable if people make internal kernel changes.
>

Yes, agreed. The interface must also be open for changes to accounting information
that might be useful as a result of new features, like containers, etc.

--
Warm Regards,
Balbir Singh
Linux Technology Center
IBM, ISTL
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/