Re: [RFC PATCH 0/2] Helper to isolate least-significant bit

[Petr Tesarik <ptesarik@suse.com>]

On Sat, 10 Jan 2026 01:20:59 +0800
Kuan-Wei Chiu <visitorckw@gmail.com> wrote:

> Hi Petr,
> 
> On Fri, Jan 09, 2026 at 05:41:34PM +0100, Petr Tesarik wrote:
> > Isolation of the least significant bit can be achieved with 3 basic
> > ALU operations which are already open-coded in various places in the
> > kernel.
> > 
> > However, since other places less efficient constructs, for example
> > `1UL << ffs(x)`, I assume the trick is known only to some authors, and
> > it's worth adding a helper to promote its use.  
> 
> Just out of curiosity, are there any existing users employing 1 <<
> ffs(x) (or other inefficient variants) in performance-critical
> hotpaths?
>
> From a quick grep, I only found one instance in drivers/clk/ti/mux.c
> matching the 1 << ffs(x) pattern. However, this doesn't appear to be a
> bottleneck since it is followed by ti_clk_ll_ops->clk_writel(...). The
> latency of the MMIO write would likely overshadow the savings of a few
> ALU cycles.

Most expressions are a bit more complex, like this one in
page_cache_async_ra():

  align = 1UL << min(ra->order, ffs(max_pages) - 1);

Or split across multiple lines, like this one in sata_down_spd_limit():

  bit = ffs(mask) - 1;
  mask = 1 << bit;

I agree that there is most likely no measurable performance win. The
resulting machine code merely looks quite silly on architectures
without an instruction to do ffs() and a little bit silly on
architectures where the instruction has a slightly different semantics
(bit position numbering and/or handling of zero value).

> Additionally, it seems that patch #2 focuses on replacing the x & -x
> implementation with the new API, rather than converting inefficient
> constructs like 1 << ffs(x) to use ffs_val().

This is correct. This patch series merely introduces the helper. Patch
2/2 was created mechanically. I haven't sent any follow-up yet to
replace inefficient use, because that would require more effort, and I'm
trying to get some early feedback first (that's why the series is
tagged RFC).

If we agree that it's worth the effort, and I split the patches by
subsystem, it may become a rather long series.

Petr T