linux-kernel - Re: [PATCH] timekeeping: move multigrain ctime floor handling into timekeeper

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: <8de7cfc4958a739f3ce9dd3699a1a53fbb9dd074.camel@kernel.org>
Date: Thu, 12 Sep 2024 08:39:32 -0400
From: Jeff Layton <jlayton@...nel.org>
To: Christian Brauner <brauner@...nel.org>
Cc: Alexander Viro <viro@...iv.linux.org.uk>, Jan Kara <jack@...e.cz>, John
 Stultz <jstultz@...gle.com>, Thomas Gleixner <tglx@...utronix.de>, Stephen
 Boyd <sboyd@...nel.org>,  Arnd Bergmann <arnd@...nel.org>,
 linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org, kernel test
 robot <oliver.sang@...el.com>
Subject: Re: [PATCH] timekeeping: move multigrain ctime floor handling into
 timekeeper

On Thu, 2024-09-12 at 14:31 +0200, Christian Brauner wrote:
> On Wed, Sep 11, 2024 at 08:56:56AM GMT, Jeff Layton wrote:
> > The kernel test robot reported a performance regression in some
> > will-it-scale tests due to the multigrain timestamp patches. The data
> > showed that coarse_ctime() was slowing down current_time(), which is
> > called frequently in the I/O path.
> > 
> > Add ktime_get_coarse_real_ts64_with_floor(), which returns either the
> > coarse time or the floor as a realtime value. This avoids some of the
> > conversion overhead of coarse_ctime(), and recovers some of the
> > performance in these tests.
> > 
> > The will-it-scale pipe1_threads microbenchmark shows these averages on
> > my test rig:
> > 
> > 	v6.11-rc7:			83830660 (baseline)
> > 	v6.11-rc7 + mgtime series:	77631748 (93% of baseline)
> > 	v6.11-rc7 + mgtime + this:	81620228 (97% of baseline)
> > 
> > Reported-by: kernel test robot <oliver.sang@...el.com>
> > Closes: https://lore.kernel.org/oe-lkp/202409091303.31b2b713-oliver.sang@intel.com
> > Suggested-by: Arnd Bergmann <arnd@...nel.org>
> > Signed-off-by: Jeff Layton <jlayton@...nel.org>
> > ---
> > Arnd suggested moving this into the timekeeper when reviewing an earlier
> > version of this series, and that turns out to be better for performance.
> > 
> > I'm not sure how this should go in (if acceptable). The multigrain
> > timestamp patches that this would affect are in Christian's tree, so
> > that may be best if the timekeeper maintainers are OK with this
> > approach.
> 
> We will need this as otherwise we can't really merge the multigrain
> timestamp work with known performance regressions?

Yes, I think we'll need something here. Arnd suggested an alternative
way to do this that might be even better. I'm not 100% sure that it'll
work though since the approach is a bit different.

I'd still like to see this go in for v6.12, so what I'd probably prefer
is to take this patch initially (with the variable name change that
John suggested), and then we can work on the alternative approach in
the meantime

Would that be acceptable?
-- 
Jeff Layton <jlayton@...nel.org>