Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Mon, 30 Mar 2020 09:29:20 +0200
Message-ID: <s5hv9mmb8rz.wl-tiwai@suse.de>
From:   Takashi Iwai <tiwai@suse.de>
To:     George Spelvin <lkml@SDF.ORG>
Cc:     James Bottomley <James.Bottomley@HansenPartnership.com>,
        linux-kernel@vger.kernel.org, Hannes Reinecke <hare@suse.de>,
        linux-scsi@vger.kernel.org,
        Marek Lindner <mareklindner@neomailbox.ch>,
        Simon Wunderlich <sw@simonwunderlich.de>,
        Antonio Quartulli <a@unstable.cc>,
        Sven Eckelmann <sven@narfation.org>,
        b.a.t.m.a.n@diktynna.open-mesh.org,
        Johannes Berg <johannes@sipsolutions.net>,
        linux-wireless@vger.kernel.org, Jaroslav Kysela <perex@perex.cz>,
        Takashi Iwai <tiwai@suse.com>, alsa-devel@alsa-project.org,
        lkml@sdf.org
Subject: Re: [RFC PATCH v1 13/50] Avoid some useless msecs/jiffies conversions
In-Reply-To: <20200330065105.GB9333@SDF.ORG>
References: <202003281643.02SGhBrh000992@sdf.org>
        <s5ho8sfd2dk.wl-tiwai@suse.de>
        <20200329121129.GC11951@SDF.ORG>
        <s5h7dz3ccea.wl-tiwai@suse.de>
        <20200329175032.GE4675@SDF.ORG>
        <1585505807.4510.1.camel@HansenPartnership.com>
        <s5hzhbybbnu.wl-tiwai@suse.de>
        <20200330065105.GB9333@SDF.ORG>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka)
 FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 Emacs/25.3
 (x86_64-suse-linux-gnu) MULE/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Mon, 30 Mar 2020 08:51:05 +0200,
George Spelvin wrote:
> 
> On Mon, Mar 30, 2020 at 08:27:01AM +0200, Takashi Iwai wrote:
> > On Sun, 29 Mar 2020 20:16:47 +0200, James Bottomley wrote:
> >> We all assume that msecs_to_jiffies is properly optimized so there
> >> should be no need to open code it like you're proposing.
> > 
> > Yes, it'd be best if the compiler can handle it properly.
> 
> I've tried, and can't figure out how to get the compiler to detect this 
> special case and not invoke the general code.  In particular, for a 
> variable x, __builtin_constant_p(x * 1000 % 1000) is false.  Even if x is 
> signed and ANSI lets the compiler assume that overflow doesn't happen.
> 
> If you can do it, I'm most curious how!

Actually in the very early version of msecs_to_jiffies() was all
inlined, so the compiler could optimize such a case, I guess.  Now it
was factored out to an external function in commit ca42aaf0c861, so it
became difficult.

> > But also I meant to keep using the macro for consistency reason.
> > IIRC, we wanted to eliminate the explicit use of HZ in the past, and
> > it's how many lines have been converted with *_to_jiffies() calls.
> > I don't know whether the eliminate of HZ is still wished, but
> > reverting to the open code is a step backward for that.
> 
> Well, you could always add a secs_to_jiffies(x) wrapper.  But given
> that it expands to basically x * HZ, some people might wonder why
> you're bothering.

Well, comparing with the expanded result doesn't make always sense.
With such a logic, you can argue why BIT(x) macro is needed, too.
After all, it's a matter of semantics.

> I assumed that open-coding x * HZ was the preferred style, so that's
> what I did.

That's my question, too -- whether the open code is preferred for this
particular purpose.


thanks,

Takashi