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
next prev parent 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®