All of lore.kernel.org
 help / color / mirror / Atom feed
From: Balbir Singh <balbir@linux.vnet.ibm.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Maxim Uvarov <muvarov@ru.mvista.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Shailabh Nagar <nagar@watson.ibm.com>,
	Balbir Singh <balbir@in.ibm.com>, Jay Lan <jlan@engr.sgi.com>
Subject: Re: [PATCH] Performance Stats: Kernel patch
Date: Tue, 05 Jun 2007 12:20:28 +0530	[thread overview]
Message-ID: <466507B4.2070802@linux.vnet.ibm.com> (raw)
In-Reply-To: <20070604121955.734de15e.akpm@linux-foundation.org>

Andrew Morton wrote:
> On Wed, 30 May 2007 18:49:46 +0000
> Maxim Uvarov <muvarov@ru.mvista.com> 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

  parent reply	other threads:[~2007-06-05  6:56 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-30 18:49 [PATCH] Performance Stats: Kernel patch Maxim Uvarov
2007-06-04 19:19 ` Andrew Morton
2007-06-04 19:33   ` Jay Lan
2007-06-04 19:49     ` Jonathan Lim
2007-06-04 20:13   ` Jay Lan
2007-06-05  6:50   ` Balbir Singh [this message]
  -- strict thread matches above, loose matches on Subject: below --
2007-06-05 14:43 Maxim Uvarov
2007-06-06  6:38 ` Andrew Morton
2007-06-06 17:29   ` Jay Lan
2007-05-22 17:19 Maxim Uvarov
2007-05-22 17:19 ` Maxim Uvarov
2007-05-22 18:48 ` Dave Jones
2007-05-22 18:48   ` Dave Jones
2007-05-22 20:08 ` Andrew Morton
2007-05-22 20:08   ` Andrew Morton
2007-05-11 17:13 Maxim Uvarov
2007-05-11 17:13 ` Maxim Uvarov
2007-05-12 10:39 ` Andrea Righi
2007-05-12 10:39   ` Andrea Righi
2007-05-10 17:19 Maxim Uvarov
2007-05-10 23:31 ` Andi Kleen
2007-05-11 16:55   ` Maxim Uvarov
2007-05-10 12:39 Maxim Uvarov
2007-05-10 12:38 ` Josh Boyer
2007-05-10 18:23   ` Maxim Uvarov
2007-05-10 11:42 Maxim Uvarov
2007-05-10 12:03 ` Pavel Machek
2007-05-10 18:25 ` Andrew Morton
2007-05-08 16:26 Maxim Uvarov
2007-05-08 19:32 ` Andrew Morton
2007-05-10 11:11   ` Maxim Uvarov
2007-05-10 18:12     ` Andrew Morton
2007-05-11 16:51       ` Maxim Uvarov
2007-05-08 23:32 ` Linas Vepstas
2007-05-10 10:22   ` Maxim Uvarov
2007-05-10 16:47     ` Linas Vepstas
     [not found] <4625FFCF.8040402@ru.mvista.com>
2007-04-20  4:36 ` [patch] " Andrew Morton
2007-04-25 10:59   ` Maxim Uvarov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=466507B4.2070802@linux.vnet.ibm.com \
    --to=balbir@linux.vnet.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=balbir@in.ibm.com \
    --cc=jlan@engr.sgi.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=muvarov@ru.mvista.com \
    --cc=nagar@watson.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.