From: Shailabh Nagar <nagar@watson.ibm.com>
To: Jay Lan <jlan@engr.sgi.com>
Cc: Balbir Singh <balbir@in.ibm.com>,
LKML <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@osdl.org>,
Chris Sturtivant <csturtiv@sgi.com>
Subject: Re: ON/OFF control of taskstats accounting data at do_exit
Date: Thu, 15 Jun 2006 11:55:39 -0400 [thread overview]
Message-ID: <449182FB.6020907@watson.ibm.com> (raw)
In-Reply-To: <4490D515.8070308@engr.sgi.com>
Jay Lan wrote:
>
> I was talking about turning off system-wise taskstats data preparation and
> delivery when every task exits. Sometimes customers like to do some
> benchmarking and need to turn off nonessential features.
Lets go through the implications of turning on/off collection, assembly and delivery
of the per-task accounting data.
Collection is defined by different subsystems using taskstats.
For atleast one of these (delay accounting), turning on/off dynamically has been tried
and deemed to cause a lot of overhead (due to accumalated nature of data) and also be
prone to races. Complexity of code added did not justify the value so on/off was restricted
to a boot time decision.
Assembly and delivery of data is done by the taskstats code, calling subsystem-specific functions to fill
the commonly used struct taskstats and relying on genetlink to do the delivery.
This can be turned on/off using a dynamic parameter such as /sys/kernel/taskstats_enable which sets
some internal variable that is used to do early exits from relevant functions (mainly taskstats_send_stats
and taskstats_exit_send)
Doing so will have impact on
a) queries sent to the kernel by monitoring applications
b) task exit data sent by kernel to apps listening on the multicast socket
For consistency, I'm assuming both a) and b) will have to be affected when taskstats is turned off.
Also, I'm assuming monitoring applications aren't aware of the turn off.
What happens to case a) ? Apps will need to get some error message as a reply. Some assembly overhead
is saved (since such an error reply can be sent right away as soon as a query command is seen) but no
substantial saving on the delivery part.
For case b), we can save on assembly and delivery by exiting early from taskstats_exit_send(). But won't
we need to send some message (if not periodically, atleast once) to listening apps that they shouldn't
expect any exit data ? Semantics of suddenly not seeing any exit data could be misinterpreted ?
Its easy enough to implement...just concerned about the semantics of doing so (as far as userspace
apps are concerned) and utility in general settings. Utility in case where only CSA is running (delay
accounting and other users turned off) is clear.
Thoughts ?
--Shailabh
next prev parent reply other threads:[~2006-06-15 15:56 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-06-14 22:55 ON/OFF control of taskstats accounting data at do_exit Jay Lan
2006-06-15 3:01 ` Balbir Singh
2006-06-15 3:02 ` Shailabh Nagar
2006-06-15 3:33 ` Jay Lan
2006-06-15 14:52 ` Shailabh Nagar
2006-06-15 15:55 ` Shailabh Nagar [this message]
2006-06-15 17:24 ` Jay Lan
2006-06-15 18:14 ` Balbir Singh
2006-06-15 18:57 ` Jay Lan
2006-06-15 18:28 ` Shailabh Nagar
2006-06-15 23:41 ` Peter Williams
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=449182FB.6020907@watson.ibm.com \
--to=nagar@watson.ibm.com \
--cc=akpm@osdl.org \
--cc=balbir@in.ibm.com \
--cc=csturtiv@sgi.com \
--cc=jlan@engr.sgi.com \
--cc=linux-kernel@vger.kernel.org \
/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