From: deepthi <deepthi@linux.vnet.ibm.com>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: linuxppc-dev@ozlabs.org, linux-pm@lists.linux-foundation.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] perf_events: Enable idle state tracing for pseries (ppc64)
Date: Tue, 21 Jun 2011 21:59:18 +0530 [thread overview]
Message-ID: <4E00C6DE.1030001@linux.vnet.ibm.com> (raw)
In-Reply-To: <1308606133.32158.143.camel@pasglop>
On Tuesday 21 June 2011 03:12 AM, Benjamin Herrenschmidt wrote:
> On Mon, 2011-06-20 at 22:48 +0530, deepthi wrote:
>> On Friday 17 June 2011 09:54 AM, Benjamin Herrenschmidt wrote:
>>> On Wed, 2011-06-01 at 18:05 +0530, Deepthi Dharwar wrote:
>>>> Hi,
>>>>
>>>> Please find below a patch, which has perf_events added for pseries (ppc64)
>>>> platform in order to emit the trace required for perf timechart.
>>>> It essentially enables perf timechart for pseries platfrom to analyse
>>>> power savings events like cpuidle states.
>>>
>>> Unless I'm mistaken, you added traces to dedicated CPU idle sleep but
>>> not shared processor. Any reason ?
>>>
>> Yes, the traces were added only to dedicated CPU idle sleep and not for
>> shared processor. This was added only for RFC purpose, and looking for
>> comments from trace implementation point of view. This can be
>> easily extended to the latter too.
>
> Please do both.
>
Yes, I ll do so.
>>> Also I don't really know that tracing stuff but what's the point of
>>> having start/end _and trace_cpu_idle if you're going to always start &
>>> end around a single occurence of trace_cpu_idle ?
>>>
>> power_start/end are the APIs that were used initially
>> and they are going to be deprecated in the upcoming kernel releases.
>> trace_cpu_idle call is going to replace power start/end routines.
>> To maintain backward compatibility and uniformity, both the routines
>> have been used.
>> (ref:https://lkml.org/lkml/2010/11/14/60ref:https://lkml.org/lkml/2010/11/14/60)
>
> Backward compatible with what ? Userspace ? Do we care in that specific
> case since it's a new feature ?
>
Going forward, we can just have trace_cpu_idle call and
remove the power_start/end calls.
>>> Wouldn't there be a way to start/end and then trace the snooze and
>>> subsequent cede within the same start/end section or that makes no
>>> sense ?
>>>
>> We wanted to find the residency time of both Snooze as well as cede
>> separately. Knowing this will help us tweak our cpuidle code. So, both
>> have been captured separately.
>>
>>> Also would there be any interest in doing the tracing more generically
>>> in idle.c ?
>>>
>> Yes, this tracing is already implemented for Intel platform. This would
>> be a part of cpuidle framework. Going further, once the power cpuidle
>> framework is ported and ready, we will extend this trace there as well.
>> (ref:https://lkml.org/lkml/2011/6/7/375)
>
> So do we need to apply this patch at all since the cpuidle stuff is
> happening too ?
>
Well, not really. This is more for RFC purpose.
I just wanted to share this patch, as we are using it to evaluate
cpu idle on ppc64.
> Cheers,
> Ben.
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
next prev parent reply other threads:[~2011-06-21 16:30 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-01 12:35 [PATCH] perf_events: Enable idle state tracing for pseries (ppc64) Deepthi Dharwar
2011-06-17 4:24 ` Benjamin Herrenschmidt
2011-06-17 4:24 ` Benjamin Herrenschmidt
2011-06-20 17:18 ` deepthi
2011-06-20 21:42 ` Benjamin Herrenschmidt
2011-06-21 16:29 ` deepthi
2011-06-21 16:29 ` deepthi [this message]
2011-06-21 16:40 ` Deepthi Dharwar
2011-06-21 16:40 ` Deepthi Dharwar
2011-06-20 21:42 ` Benjamin Herrenschmidt
2011-06-20 17:18 ` deepthi
-- strict thread matches above, loose matches on Subject: below --
2011-06-01 12:35 Deepthi Dharwar
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=4E00C6DE.1030001@linux.vnet.ibm.com \
--to=deepthi@linux.vnet.ibm.com \
--cc=benh@kernel.crashing.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@lists.linux-foundation.org \
--cc=linuxppc-dev@ozlabs.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 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.