mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Balbir Singh <balbir@in.ibm.com>
To: Jay Lan <jlan@engr.sgi.com>
Cc: Shailabh Nagar <nagar@watson.ibm.com>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	LSE <lse-tech@lists.sourceforge.net>
Subject: Re: [Lse-tech] Re: [Patch 5/8] taskstats interface
Date: Sat, 29 Apr 2006 00:05:59 +0530	[thread overview]
Message-ID: <20060428183559.GB8349@in.ibm.com> (raw)
In-Reply-To: <44525CE5.3060800@engr.sgi.com>

> >Is this what you had in mind?
> >  
> No exactly. The payload information must be always available for
> application.
> 
> On a second thought, the idea of one big taskstats struct with many
> #ifconfig is not really a good idea. My goal is to cut down unnecessary
> data being transfered throught the socket.

Yes, so we agree that #ifdef CONFIG_* is not good.

> 
> Here is my Take 2. We can have a  taskstats header containing taskstats
> version and other general fields useful to more than one taskstats
> application including a payload information. Then, we define
> accounting subsystem specific structs for delayacct, csa, etc.
> The kernel/{delayacct.c,csa.c,etc.c} set the payload information and
> fill the buffer with desired subsystem structs. The header thus contain
> enough information to tell  applications how to map the data following
> the header.

I agree with this suggestion.

Each netlink attribute contains the following fields (also referred to as TLV)

+----+--------+------+
|Type| length | value|
+----+--------+------+

The type is meant to serve the purpose of the header you describe. The
type value can be used by the application to map the data. 
getdelays.c is a sample application posted in the previous patches,
it interprets data based on type.


> 
> Would IBM propose more accounting subsystems besides delayacct?
> If we only see delayacct and csa on the horizon, this scheme is really
> not necessary since delayacct does not have as much data (as csa :))
> and csa can use part of the delayacct data. You gain more than
> csa can benefit from this. ;-) I guess i just speak from design point
> of view. :)
> 
> But, if one day somebody who does not need a paycheck decides
> to convert BSD accounting to use taskstats interface, this can
> be helpful.
> 

Yes, I think in the long term it would be more useful to use the scheme
of adding subsystem structs. taskstats.txt explains the process of 
extending taskstats. Point #2 is the same as what we have just discussed.
Could you please see if the text needs any changes based on our discussions
so far (taskstats.txt was posted in the delayacct-doc.patch).

> Thanks,
>  - jay
> 
> 

-- 
					<---	Balbir

  reply	other threads:[~2006-04-28 18:38 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-04-22  2:16 [Patch 0/8] per-task delay accounting Shailabh Nagar
2006-04-22  2:23 ` [Patch 1/8] Setup Shailabh Nagar
2006-04-24  2:02   ` Randy.Dunlap
2006-04-24 17:26     ` Shailabh Nagar
2006-04-22  2:29 ` [Patch 2/8] Sync block I/O and swapin delay collection Shailabh Nagar
2006-04-22  2:33 ` [Patch 3/8] cpu delay collection via schedstats Shailabh Nagar
2006-04-22  2:35 ` [Patch 4/8] Utilities for genetlink usage Shailabh Nagar
2006-04-22  2:37 ` [Patch 5/8] taskstats interface Shailabh Nagar
2006-04-27  1:12   ` Jay Lan
2006-04-27  4:00     ` Shailabh Nagar
2006-04-27  6:42       ` [Lse-tech] " Balbir Singh
2006-04-27 17:52         ` Jay Lan
2006-04-27 18:27           ` Balbir Singh
2006-04-27 19:34             ` Jay Lan
2006-04-28  2:59               ` Balbir Singh
2006-04-28 18:20                 ` Jay Lan
2006-04-28 18:35                   ` Balbir Singh [this message]
2006-04-22  2:39 ` [Patch 6/8] delay accounting usage of " Shailabh Nagar
2006-04-22  2:40 ` [Patch 7/8] documentation Shailabh Nagar
2006-04-22  2:42 ` [Patch 8/8] /proc export of aggregated block I/O delays Shailabh Nagar
2006-04-22  7:46   ` [Lse-tech] " Andi Kleen
2006-04-25 15:07 ` [Patch 0/8] per-task delay accounting Shailabh Nagar

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=20060428183559.GB8349@in.ibm.com \
    --to=balbir@in.ibm.com \
    --cc=jlan@engr.sgi.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lse-tech@lists.sourceforge.net \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®