Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753998AbdLNSek (ORCPT ); Thu, 14 Dec 2017 13:34:40 -0500 Received: from mail.kernel.org ([198.145.29.99]:53810 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753734AbdLNSej (ORCPT ); Thu, 14 Dec 2017 13:34:39 -0500 DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 59D8F218D1 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=abelloni@kernel.org Date: Thu, 14 Dec 2017 19:34:34 +0100 From: Alexandre Belloni To: Steven Rostedt Cc: Baolin Wang , a.zummo@towertech.it, mingo@redhat.com, linux-rtc@vger.kernel.org, linux-kernel@vger.kernel.org, arnd@arndb.de, broonie@kernel.org Subject: Re: [PATCH v3] rtc: Add tracepoints for RTC system Message-ID: <20171214183434.GE2559@piout.net> References: <20171214124912.3171dafd@gandalf.local.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171214124912.3171dafd@gandalf.local.home> User-Agent: Mutt/1.9.1 (2017-09-22) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1988 Lines: 67 Hi Steve, (Writing from my @kernel.org email to ensure you receive it) On 14/12/2017 at 12:49:12 -0500, Steven Rostedt wrote: > On Thu, 14 Dec 2017 13:31:43 +0800 > Baolin Wang wrote: > > > > @@ -53,6 +56,8 @@ int rtc_read_time(struct rtc_device *rtc, struct rtc_time *tm) > > > > err = __rtc_read_time(rtc, tm); > > mutex_unlock(&rtc->ops_lock); > > + > > + trace_rtc_read_time(rtc_tm_to_time64(tm), err); > > There's a possibility that gcc may put the call to rt_tm_to_time64() > outside the tracepoint area that gets nop'd out. Could you just pass in > the tm to the tracepoint, and have the call to rtc_tm_to_time64() done > within the TP_fast_assign? This would guarantee that we don't incur > overhead when tracing is off. > Actually, I've asked for that as rtc_time64_to_tm is really heavier than rtc_tm_to_time64 and both set_time and set_alarm will soon have a call to rtc_tm_to_time64 anyway. read_time and read_alarm will probably end up having one in the long term too. > > diff --git a/include/trace/events/rtc.h b/include/trace/events/rtc.h > > new file mode 100644 > > index 0000000..621333f > > --- /dev/null > > +++ b/include/trace/events/rtc.h > > @@ -0,0 +1,206 @@ > > +#undef TRACE_SYSTEM > > +#define TRACE_SYSTEM rtc > > + > > +#if !defined(_TRACE_RTC_H) || defined(TRACE_HEADER_MULTI_READ) > > +#define _TRACE_RTC_H > > + > > +#include > > +#include > > + > > +DECLARE_EVENT_CLASS(rtc_time_alarm_class, > > + > > + TP_PROTO(time64_t secs, int err), > > + > > + TP_ARGS(secs, err), > > + > > + TP_STRUCT__entry( > > + __field(time64_t, secs) > > + __field(int, err) > > + ), > > + > > + TP_fast_assign( > > + __entry->secs = secs; > > + __entry->err = err; > > + ), > > + > > + TP_printk("UTC (%lld) (%d)", > > + __entry->secs, __entry->err Can't TP_printk do the rtc_time64_to_tm conversion to pretty print the date? Or do we have to implement it in vsprintf? -- Alexandre Belloni