From: Satoru Takeuchi <takeuchi_satoru@jp.fujitsu.com>
To: Ciju Rajan K <ciju@linux.vnet.ibm.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>,
lkml <linux-kernel@vger.kernel.org>, Ingo Molnar <mingo@elte.hu>,
Bharata B Rao <bharata@linux.vnet.ibm.com>,
Srivatsa Vaddagiri <vatsa@in.ibm.com>
Subject: Re: [RFC][PATCH 0/2 v1.0]sched: updating /proc/schedstat
Date: Tue, 18 Jan 2011 16:29:48 +0900 [thread overview]
Message-ID: <4D35416C.7020706@jp.fujitsu.com> (raw)
In-Reply-To: <4D352CA6.7010109@linux.vnet.ibm.com>
Hi Ciju,
(2011/01/18 15:01), Ciju Rajan K wrote:
> Hi Peter,
>
>
> On 01/17/2011 10:24 PM, Peter Zijlstra wrote:
>> On Mon, 2011-01-17 at 16:19 +0530, Ciju Rajan K wrote:
>>> Hi All,
>>>
>>> Here is the first version of the patch set, which updates
>>> the /proc/schedstat statistics. Please review the patches and let me
>>> know your thoughts.
>>
>> Whats the impact on existing userspace, does the change warrant the
>> effort of changing the userspace tools?
>
> Since the fields are not at the end, there might be some changes required for the userspace scripts. But the benefits would be that we will have more relevant stats in /proc/schedstat.
>
> Most of the userspace applications will be considering the version field of /proc/schedstat. Since we have an updated version for these changes, there should not be any breakage for the existing applications. One more advantage is that who ever looks at /proc/schedstat will see the actual numbers rather than seeing more zeros. Basically the readability improves.
>
> "http://eaglet.rain.com/rick/linux/schedstat/" admits that the format for /proc/schedstat can change depending upon the version. If you are ok with the /proc/schedstat updates, I can also send a patch to update "http://eaglet.rain.com/rick/linux/schedstat/v15/latency.c" program which parses some of the schedstat entries.
I don't like this patches because it breaks backward compatibility.
If there are any user who uses these fields, they can't get
the information which these fields provides from this time on.
In this context, `user' means not only application but also the person
who refers to /proc/schedstat directly.
In fact, although I can't say "command XXX refers to these field",
I sometimes check {sbe_*,sbf_*} to confirm load_balance behavior
by issuing, for example,
===============================================================================
watch /proc/schedstat
===============================================================================
or
===============================================================================
while true ; do
cat /proc/schedstat >>schedstat_log
sleep 10
done
===============================================================================
Thanks
Satoru
>
>
>>
>> Also, attachment fail.
>
> It should be ok now.
>
> -Ciju
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
>
next prev parent reply other threads:[~2011-01-18 7:30 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-17 10:49 [RFC][PATCH 0/2 v1.0]sched: updating /proc/schedstat Ciju Rajan K
2011-01-17 10:52 ` [PATCH 1/2 v1.0]sched: Removing unused fields from /proc/schedstat Ciju Rajan K
2011-01-17 10:54 ` [PATCH 2/2 v1.0]sched: Updating the sched-stat documentation Ciju Rajan K
2011-01-17 16:54 ` [RFC][PATCH 0/2 v1.0]sched: updating /proc/schedstat Peter Zijlstra
2011-01-18 6:01 ` Ciju Rajan K
2011-01-18 6:04 ` [PATCH 1/2 v1.0]sched: Removing unused fields from /proc/schedstat Ciju Rajan K
2011-01-18 6:04 ` [PATCH 2/2 v1.0]sched: Updating the sched-stat documentation Ciju Rajan K
2011-01-19 7:11 ` Satoru Takeuchi
2011-01-19 15:47 ` Ciju Rajan K
2011-01-18 7:29 ` Satoru Takeuchi [this message]
2011-01-18 7:50 ` [RFC][PATCH 0/2 v1.0]sched: updating /proc/schedstat Ciju Rajan K
2011-01-19 6:42 ` Satoru Takeuchi
2011-01-19 15:55 ` Ciju Rajan K
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=4D35416C.7020706@jp.fujitsu.com \
--to=takeuchi_satoru@jp.fujitsu.com \
--cc=a.p.zijlstra@chello.nl \
--cc=bharata@linux.vnet.ibm.com \
--cc=ciju@linux.vnet.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=vatsa@in.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