mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Baolin Wang <baolin.wang@linaro.org>
Cc: a.zummo@towertech.it, alexandre.belloni@free-electrons.com,
	rostedt@goodmis.org, mingo@redhat.com, john.stultz@linaro.org,
	broonie@kernel.org, linux-kernel@vger.kernel.org,
	rtc-linux@googlegroups.com
Subject: Re: [PATCH 2/2] time: alarmtimer: Add the trcepoints for alarmtimer
Date: Wed, 21 Sep 2016 00:27:35 +0200 (CEST)	[thread overview]
Message-ID: <alpine.DEB.2.20.1609202340560.5476@nanos> (raw)
In-Reply-To: <0d5cedb2f4ad46aa7fb07b990072bacb33517102.1474177609.git.baolin.wang@linaro.org>

On Sun, 18 Sep 2016, Baolin Wang wrote:
> +DECLARE_EVENT_CLASS(alarm_setting,

What is alarm_setting? Without looking at the DEFINE_EVENT which uses this
I cannot decode the meaning.

> +	TP_STRUCT__entry(
> +		__field(unsigned char, second)
> +		__field(unsigned char, minute)
> +		__field(unsigned char, hour)
> +		__field(unsigned char, day)
> +		__field(unsigned char, mon)
> +		__field(unsigned short, year)
> +		__field(unsigned char, alarm_type)
> +	),
> +
> +	TP_fast_assign(
> +		__entry->second = rtc_time->tm_sec;
> +		__entry->minute = rtc_time->tm_min;
> +		__entry->hour = rtc_time->tm_hour;
> +		__entry->day = rtc_time->tm_mday;
> +		__entry->mon = rtc_time->tm_mon;
> +		__entry->year = rtc_time->tm_year;
> +		__entry->alarm_type = flag;

What's the value of storing the alarm time in RTC format?

What's wrong with simply storing the flat u64 based wall clock time?
Nothing, because you can do the RTC format conversion in user space.

> +DECLARE_EVENT_CLASS(alarm_processing,

Again alarm_processing is not telling me anything. 

> +
> +	TP_PROTO(struct alarm *alarm, char *process_name),

Why do you want to store process_name? The tracer already tracks the name
of the process in which context the tracepoint is taken. So what's the
point of this? Look at the output:

system_server-2976  [003] d..2  1076.605608: alarmtimer_start: process:system_server

Completely pointless duplicated information.

> +
> +	TP_ARGS(alarm, process_name),
> +
> +	TP_STRUCT__entry(
> +		__field(unsigned long long, expires)
> +		__field(unsigned char, second)
> +		__field(unsigned char, minute)
> +		__field(unsigned char, hour)
> +		__field(unsigned char, day)
> +		__field(unsigned char, mon)
> +		__field(unsigned short, year)
> +		__field(unsigned char, alarm_type)
> +		__string(name, process_name)
> +	),
> +
> +	TP_fast_assign(
> +		__entry->expires = alarm->node.expires.tv64;
> +		__entry->alarm_type = alarm->type;
> +		__assign_str(name, process_name);
> +		__entry->second = rtc_ktime_to_tm(alarm->node.expires).tm_sec;
> +		__entry->minute = rtc_ktime_to_tm(alarm->node.expires).tm_min;
> +		__entry->hour = rtc_ktime_to_tm(alarm->node.expires).tm_hour;
> +		__entry->day = rtc_ktime_to_tm(alarm->node.expires).tm_mday;
> +		__entry->mon = rtc_ktime_to_tm(alarm->node.expires).tm_mon;
> +		__entry->year = rtc_ktime_to_tm(alarm->node.expires).tm_year;

This is utter crap for various reasons:

1) You store the expiry time over and over and in most cases it's simply
   pointless.

   - If the timer is started then we want to store the expiry time.

   - If the timer fires then the programmed expiry time is available from
     the start trace point and you miss to store the information which is
     really interesting: The actual time at which the timer expires
     (REAL/BOOT)

   - If the timer is canceled then the expiry time in the timer is not
     interesting at all. All you care is about the fact that the timer has
     been canceled. The expiry time can still be retrieved from the start
     trace point.

   - The restart tracepoint is redundant as well because either you see:

     start -> expire -> start or start -> start which is clearly a restart.

     If you put the start trace point into alarmtimer_enqueue() then you
     spare the extra code size for two tracepoints because that is used in
     start and restart

   See the hrtimer and timer tracepoints for reference. 


2) You store the expiry time again in RTC format. Store the information in
   a plain u64 and be done with it.


> +DEFINE_EVENT(alarm_processing, alarmtimer_fired,
> +
> +	TP_PROTO(struct alarm *alarm, char *process_name),

So you hand in a NULL pointer to this tracepoint to have even more useless
information in the trace.

> @@ -264,6 +270,11 @@ static int alarmtimer_suspend(struct device *dev)
>  	now = rtc_tm_to_ktime(tm);
>  	now = ktime_add(now, min);
>  
> +	if (trace_alarmtimer_suspend_enabled()) {

What's the point of this conditional? Avoiding rtc_ktime_to_tm() ? Oh well...

> +		tm_set = rtc_ktime_to_tm(now);
> +		trace_alarmtimer_suspend(&tm_set, type);

"now" is CLOCK_REALTIME based. You store the type of the alarm timer which
is the first to expire and therefor is the one setting the RTC value, but
we don't know which timer it is. Useful - NOT!

Thanks,

	tglx

  reply	other threads:[~2016-09-20 22:30 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-18  6:03 [PATCH 1/2] rtc: Add some dummy static inline functions Baolin Wang
2016-09-18  6:03 ` [PATCH 2/2] time: alarmtimer: Add the trcepoints for alarmtimer Baolin Wang
2016-09-20 22:27   ` Thomas Gleixner [this message]
2016-09-21  3:25     ` Baolin Wang
2016-09-21  7:26       ` Thomas Gleixner
2016-09-21 10:58         ` Baolin Wang
2016-09-21 12:33         ` Steven Rostedt
2016-09-21 12:36           ` Thomas Gleixner
2016-09-21 13:32             ` Steven Rostedt
2016-09-20 21:36 ` [PATCH 1/2] rtc: Add some dummy static inline functions Thomas Gleixner
2016-09-21  2:01   ` Baolin Wang

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=alpine.DEB.2.20.1609202340560.5476@nanos \
    --to=tglx@linutronix.de \
    --cc=a.zummo@towertech.it \
    --cc=alexandre.belloni@free-electrons.com \
    --cc=baolin.wang@linaro.org \
    --cc=broonie@kernel.org \
    --cc=john.stultz@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=rostedt@goodmis.org \
    --cc=rtc-linux@googlegroups.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

all inboxes | Powered by JetHome®