From: Shailabh Nagar <nagar@watson.ibm.com>
To: David Rientjes <rientjes@cs.washington.edu>
Cc: Martin Tostrup Setek <martitse@student.matnat.uio.no>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH: 2.6.18.1] delayacct: cpu_count in taskstats updated correctly
Date: Fri, 27 Oct 2006 11:49:40 -0400 [thread overview]
Message-ID: <45422A94.1040402@watson.ibm.com> (raw)
In-Reply-To: <Pine.LNX.4.64N.0610262027350.12347@attu2.cs.washington.edu>
David Rientjes wrote:
> On Fri, 27 Oct 2006, Martin Tostrup Setek wrote:
>
>> from: Martin T. Setek <martitse@ifi.uio.no>
>>
>> cpu_count in struct taskstats should be the same as the corresponding (third)
>> value found in /proc/<pid>/schedstat
>
> I disagree in favor of Documentation/accounting/taskstats-struct.txt.
> cpu_count is the number of delay values recorded, so accumulating them is
> appropriate.
>
> David
David's right. The delay accounting field cpu_count
is measuring how many delay values are recorded in the field cpu_delay_total
(so that one can divide one by the other to get an average if needed).
For the delays reported for a single task (ie. __delayacct_add_tsk called only
once for a given task), the effect will be what Martin wants i.e. cpu_count will be
the same as /proc/pid/schedstat's third field (sched_info->pcnt)
But when the delays are reported for a tgid, where *accumalation* of delays for
all constituent pids is being done (by calling __delayacct_add_tsk repeatedly), what
is desired is to accumalate both cpu_count and cpu_delay_total.
So the patch proposed by Martin is incorrect.
--Shailabh
prev parent reply other threads:[~2006-10-27 15:50 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-27 3:18 [PATCH: 2.6.18.1] delayacct: cpu_count in taskstats updated correctly Martin Tostrup Setek
2006-10-27 3:29 ` David Rientjes
2006-10-27 4:47 ` Martin Tostrup Setek
2006-10-27 5:51 ` David Rientjes
2006-10-27 7:23 ` Martin Tostrup Setek
2006-10-27 15:49 ` Shailabh Nagar [this message]
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=45422A94.1040402@watson.ibm.com \
--to=nagar@watson.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=martitse@student.matnat.uio.no \
--cc=rientjes@cs.washington.edu \
/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.