From: Nick Piggin <nickpiggin@yahoo.com.au>
To: balbir@in.ibm.com
Cc: Andrew Morton <akpm@osdl.org>,
linux-kernel@vger.kernel.org, lse-tech@lists.sourceforge.net,
jlan@engr.sgi.com
Subject: Re: [Patch 2/8] Sync block I/O and swapin delay collection
Date: Tue, 09 May 2006 14:23:15 +1000 [thread overview]
Message-ID: <44601933.2040905@yahoo.com.au> (raw)
In-Reply-To: <20060509035320.GC784@in.ibm.com>
Balbir Singh wrote:
>On Mon, May 08, 2006 at 02:19:52PM -0700, Andrew Morton wrote:
>
>>Balbir Singh <balbir@in.ibm.com> wrote:
>>
>>>@@ -550,6 +550,12 @@ struct task_delay_info {
>>> * Atomicity of updates to XXX_delay, XXX_count protected by
>>> * single lock above (split into XXX_lock if contention is an issue).
>>> */
>>>+
>>>+ struct timespec blkio_start, blkio_end; /* Shared by blkio, swapin */
>>>+ u64 blkio_delay; /* wait for sync block io completion */
>>>+ u64 swapin_delay; /* wait for swapin block io completion */
>>>+ u32 blkio_count;
>>>+ u32 swapin_count;
>>>
>>These fields are a bit mystifying.
>>
>>In what units are blkio_delay and swapin_delay?
>>
>>What is the meaning behind blkio_count and swapin_count?
>>
>>Better comments needed, please.
>>
>
>Will add more detailed comments and send them as updates.
>
What kinds of usages will this stuff see? Will the CONFIG be usually
turned on,
with some tasks occasionally using the statistics?
In which case, might it be better to make each delay collector in its
own data
structure { .list; .start; .end; .delay; .count; .private; .name }, and
allocate
them and hang them off the task structure when they're in use?
Or even put them in their own data structure (a small hash or something).
OTOH if they're often going to be in use by many tasks, then what you
have might
be the best option.
Nick
Send instant messages to your online friends http://au.messenger.yahoo.com
next prev parent reply other threads:[~2006-05-09 4:36 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-05-02 6:14 [Patch 2/8] Sync block I/O and swapin delay collection Balbir Singh
2006-05-08 21:19 ` Andrew Morton
2006-05-09 3:53 ` Balbir Singh
2006-05-09 4:23 ` Nick Piggin [this message]
2006-05-09 5:45 ` Balbir Singh
2006-05-09 5:57 ` Nick Piggin
2006-05-09 8:06 ` Balbir Singh
2006-05-09 8:20 ` Nick Piggin
2006-05-09 17:27 ` Balbir Singh
2006-05-10 0:15 ` Nick Piggin
2006-05-10 10:20 ` [PATCH][delayacct] Add comments on units for the delay fields (was Re: [Patch 2/8] Sync block I/O and swapin delay collection) Balbir Singh
-- strict thread matches above, loose matches on Subject: below --
2006-04-22 2:16 [Patch 0/8] per-task delay accounting Shailabh Nagar
2006-04-22 2:29 ` [Patch 2/8] Sync block I/O and swapin delay collection 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=44601933.2040905@yahoo.com.au \
--to=nickpiggin@yahoo.com.au \
--cc=akpm@osdl.org \
--cc=balbir@in.ibm.com \
--cc=jlan@engr.sgi.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lse-tech@lists.sourceforge.net \
/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