linux-kernel - Re: [RFC PATCH v1 13/50] Avoid some useless msecs/jiffies conversions

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <s5hv9mmb8rz.wl-tiwai@suse.de>
Date:   Mon, 30 Mar 2020 09:29:20 +0200
From:   Takashi Iwai <tiwai@...e.de>
To:     George Spelvin <lkml@....ORG>
Cc:     James Bottomley <James.Bottomley@...senPartnership.com>,
        linux-kernel@...r.kernel.org, Hannes Reinecke <hare@...e.de>,
        linux-scsi@...r.kernel.org,
        Marek Lindner <mareklindner@...mailbox.ch>,
        Simon Wunderlich <sw@...onwunderlich.de>,
        Antonio Quartulli <a@...table.cc>,
        Sven Eckelmann <sven@...fation.org>,
        b.a.t.m.a.n@...tynna.open-mesh.org,
        Johannes Berg <johannes@...solutions.net>,
        linux-wireless@...r.kernel.org, Jaroslav Kysela <perex@...ex.cz>,
        Takashi Iwai <tiwai@...e.com>, alsa-devel@...a-project.org,
        lkml@....org
Subject: Re: [RFC PATCH v1 13/50] Avoid some useless msecs/jiffies conversions

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