linux-kernel - Re: [PATCH v2 00/15] timers: Cleanup delay/sleep related mess

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 for Android: free password hash cracker in your pocket

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

Message-ID: <87ttduwntj.ffs@tglx>
Date: Wed, 02 Oct 2024 17:02:00 +0200
From: Thomas Gleixner <tglx@...utronix.de>
To: Christophe JAILLET <christophe.jaillet@...adoo.fr>, Frederic Weisbecker
 <frederic@...nel.org>, Jonathan Corbet <corbet@....net>, Anna-Maria
 Behnsen <anna-maria@...utronix.de>
Cc: linux-kernel@...r.kernel.org, Len Brown <len.brown@...el.com>, "Rafael
 J. Wysocki" <rafael@...nel.org>, Anna-Maria Behnsen
 <anna-maria@...utronix.de>, Andrew Morton <akpm@...ux-foundation.org>,
 damon@...ts.linux.dev, linux-mm@...ck.org, SeongJae Park <sj@...nel.org>,
 Arnd Bergmann <arnd@...db.de>, linux-arch@...r.kernel.org, Heiner Kallweit
 <hkallweit1@...il.com>, "David S. Miller" <davem@...emloft.net>, Andy
 Whitcroft <apw@...onical.com>, Joe Perches <joe@...ches.com>, Dwaipayan
 Ray <dwaipayanray1@...il.com>, Liam Girdwood <lgirdwood@...il.com>, Mark
 Brown <broonie@...nel.org>, Andrew Lunn <andrew@...n.ch>, Jaroslav Kysela
 <perex@...ex.cz>, Takashi Iwai <tiwai@...e.com>, netdev@...r.kernel.org,
 linux-sound@...r.kernel.org, Michael Ellerman <mpe@...erman.id.au>, Nathan
 Lynch <nathanl@...ux.ibm.com>, linuxppc-dev@...ts.ozlabs.org, Mauro
 Carvalho Chehab <mchehab@...nel.org>, linux-media@...r.kernel.org
Subject: Re: [PATCH v2 00/15] timers: Cleanup delay/sleep related mess

On Mon, Sep 16 2024 at 22:20, Christophe JAILLET wrote:
> Le 11/09/2024 à 07:13, Anna-Maria Behnsen a écrit :
>
> not directly related to your serie, but some time ago I sent a patch to 
> micro-optimize Optimize usleep_range(). (See [1])
>
> The idea is that the 2 parameters of usleep_range() are usually 
> constants and some code reordering could easily let the compiler compute 
> a few things at compilation time.
>
> There was consensus on the value of the change (see [2]), but as you are 
> touching things here, maybe it makes sense now to save a few cycles at 
> runtime and a few bytes of code?

For the price of yet another ugly interface and pushing the
multiplication into the non-constant call sites.

Seriously usleep() is not a hotpath operation and the multiplication is
not even measurable except in micro benchmarks.

Thanks,

        tglx