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] [thread-next>] [day] [month] [year] [list]
Message-ID: <f32995aa-df23-bf51-adb7-f024b76a33aa@rasmusvillemoes.dk>
Date:   Mon, 21 Aug 2023 09:48:38 +0200
From:   Rasmus Villemoes <linux@...musvillemoes.dk>
To:     Yury Norov <yury.norov@...il.com>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Cc:     linux-kernel@...r.kernel.org
Subject: Re: [PATCH] bitmap: optimize bitmap_remap()

On 19/08/2023 04.03, Yury Norov wrote:
> On Thu, Aug 17, 2023 at 06:37:01PM +0300, Andy Shevchenko wrote:

>> But this gives +89 bytes on x86_64... :-(
> 
> Who cares if it gives a boost of performance for regular users?

"Regular users" never ever hit bitmap_remap, it's simply too esoteric.
It has all of _two_ users in the whole tree, one in some gpio driver,
another only reached via a system call that nobody ever uses, and if
they do, it's most likely some one-time-per-process thing. It's about as
far from a hot path that you can come.

If it wasn't for that xilinx user, those bitmap_remap and bitmap_onto
etc. should be moved to be private to the NUMA code.

Anyway, I think those +89 was for Andy's own counterproposal. I haven't
built Yury's patch, but from a quick look, it should not add that much,
if anything - it adds a test, call, early return, but OTOH it helps the
compiler to combine the two set_bit (since only the first argument
differs), and loses the lock prefix.

As for that latter point, I don't think a separate patch is worth it,
just a comment in the commit log - we're already doing a bitmap_zero()
on dst which certainly doesn't use any atomic ops, and in general all
the bitmap_* functions expect the caller to handle locking.

So I don't mind Yury's patch, but I highly doubt it matters at all. The
comment mentions an example, do we even have that put in test code?

Rasmus

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ