[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <374465d3-dceb-43b1-930e-dd4e9b7322d2@rasmusvillemoes.dk>
Date: Wed, 25 Oct 2023 10:18:00 +0200
From: Rasmus Villemoes <linux@...musvillemoes.dk>
To: kernel test robot <oliver.sang@...el.com>, Jan Kara <jack@...e.cz>
Cc: oe-lkp@...ts.linux.dev, lkp@...el.com,
Yury Norov <yury.norov@...il.com>,
linux-kernel@...r.kernel.org, ying.huang@...el.com,
feng.tang@...el.com, fengwei.yin@...el.com,
Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
Mirsad Todorovac <mirsad.todorovac@....unizg.hr>,
Matthew Wilcox <willy@...radead.org>,
linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH 1/2] lib/find: Make functions safe on changing bitmaps
On 25/10/2023 09.18, kernel test robot wrote:
>
>
> Hello,
>
> kernel test robot noticed a 3.7% improvement of will-it-scale.per_thread_ops on:
So with that, can we please just finally say "yeah, let's make the
generic bitmap library functions correct and usable in more cases"
instead of worrying about random micro-benchmarks that just show
you-win-some-you-lose-some.
Yes, users will have to treat results from the find routines carefully
if their bitmap may be concurrently modified. They do. Nobody wins if
those users are forced to implement their own bitmap routines for their
lockless algorithms.
Rasmus
Powered by blists - more mailing lists