linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Cristian Marussi <cristian.marussi@arm.com>
To: Luke Parkin <luke.parkin@arm.com>
Cc: Cristian Marussi <cristian.marussi@arm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"arm-scmi@vger.kernel.org" <arm-scmi@vger.kernel.org>,
	Sudeep Holla <Sudeep.Holla@arm.com>
Subject: Re: [PATCH 2/3] Track basic SCMI statistics
Date: Tue, 2 Jul 2024 12:10:21 +0100	[thread overview]
Message-ID: <ZoPgHRl8FUo9-Xvz@pluto> (raw)
In-Reply-To: <490bb053-f2dd-4c6a-a976-c8d21d66eb4c@arm.com>

On Tue, Jul 02, 2024 at 10:57:23AM +0100, Luke Parkin wrote:
> > Ok, so IMO, this is the main core thing to rework in this series: the
> > "counting" operation/block should be defined as a macro so that it can
> > be fully compiled out when STATS=n, because these are counters
> > incremented on the hot path for each message, not just once in a while,
> > so the above if(IS_ENABELD()) now will be there and evaluated even when
> > STATS=n.
> >
> > Something like:
> >
> > 	#ifdef CONFIG_ARM_SCMI_DEBUG_STATISTICS
> > 	#define SCMI_LOG_STATS(counter)			\
> > 		<your magic here> 			\
> > 	#else
> > 	#define SCMI_LOG_STATS(counter)
> > 	#endif
> >
> > .... I have not thought it through eh...so it could be radically
> > different...the point is ... the counting machinery should just
> > disappear at compile time when STATS=n
> 
> Hey Cristian, Unless I've missed something, It looks like IS_ENABLED() does do
> what you ask for.
> In Documentation/process/coding-style.rst:1168 it reccomends using IS_ENABLED
> for conditional compilation over #if and #ifdef, saying that the compiler will
> constant-fold the conditional away.

Yes indeed, it will be compiled out anyway, forgot that despite having
it used myself a few lines below :D .... but from the readability standpoint,
given that we will sprinkle this all over the code, wont be much clearer to
conditionally define once for all an inline function (like mentioned at the
start of that coding-style.rst paragraph) or a macro in a header (like common.h)
to wrap the atomic_inc

#ifdef CONFIG_ARM_SCMI_DEBUG_STATISTICS
static inline void scmi_log_stats(atomic_t *cnt)
{
	atomic_inc(cnt);
}
#else
static inline void scmi_log_stats(atomic_t *cnt) { }
#endif

and then just call it plainly wherever it needs, knowing that the compiler
will equally compile it out all-over when STATS=n.

ifdeffery is discouraged in the code flow but it is acceptable to define
alternative nop fucntions in a header.

Also because in some of the callsite you handle 2 stats with some ifcond
(conditional on the IS_ENABLED that is good) and that could be a problem,
but those calls can be split and placed alone where that some condition is
already check normally as in as an example in scmi_handle_response():

	if (xfer->hdr.type == MSG_TYPE_DELAYED_RESP) {                           
                scmi_clear_channel(info, cinfo);
                complete(xfer->async_done);
+		scmi_log_stats(&info->stats.dlyd_response_ok);
	} else {                                                                 
                complete(&xfer->done);                                           
+		scmi_log_stats(&info->stats.response_ok);
        }                                    

...what do you think, am I missing something else ?

Thanks,
Cristian


  reply	other threads:[~2024-07-02 11:10 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-01 14:28 [PATCH 0/3] Add Per-transport SCMI debug statistics Luke Parkin
2024-07-01 14:28 ` [PATCH 1/3] Add Kconfig option for scmi " Luke Parkin
2024-07-01 15:32   ` Cristian Marussi
2024-07-01 14:28 ` [PATCH 2/3] Track basic SCMI statistics Luke Parkin
2024-07-01 16:15   ` Cristian Marussi
2024-07-02  9:57     ` Luke Parkin
2024-07-02 11:10       ` Cristian Marussi [this message]
2024-07-02 12:50         ` Luke Parkin
2024-07-01 14:28 ` [PATCH 3/3] Create debugfs files for statistics Luke Parkin
2024-07-01 16:19   ` Cristian Marussi
2024-07-01 15:20 ` [PATCH 0/3] Add Per-transport SCMI debug statistics Cristian Marussi
2024-07-01 16:21 ` Cristian Marussi

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=ZoPgHRl8FUo9-Xvz@pluto \
    --to=cristian.marussi@arm.com \
    --cc=Sudeep.Holla@arm.com \
    --cc=arm-scmi@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luke.parkin@arm.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;
as well as URLs for NNTP newsgroup(s).