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]
Date:   Tue, 4 Jan 2022 08:40:30 +0100
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Imran Khan <imran.f.khan@...cle.com>
Cc:     tj@...nel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH v2 1/2] kernfs: use kernfs_node specific mutex and
 spinlock.

On Tue, Jan 04, 2022 at 09:16:03AM +1100, Imran Khan wrote:
> > There is a tradeoff of memory usage and runtime contention that has to
> > be made here, and this might be pushing it in the wrong direction for
> > a lot of systems.
> > 
> Agree. Could you please suggest if this should be made configurable via
> kconfig ? I understand that this would result in 2 versions of some
> functions but it will allow systems with large memories to avoid kernfs
> contention.

No, that way lies madness and horrible bugs and a codebase no one will
be able to maintain.

> We are seeing the launch time of some DB workloads adversely getting
> affected with this contention.

What workloads?  sysfs should NEVER be in the fast-path of any normal
operation, including booting.  What benchmark or real-work is having
problems here?

> Also based on recent movement of kernfs_rwsem into kernfs_root, do you
> think that the above mentioned mutex and spinlock can be moved to
> kernfs_root as well. Although that change would not help in my current
> case, but it could avoid similar contentions between different users of
> kernfs like cgroup and sysfs

Why would you want to move it if you do not see a measured benefit?

thanks,

greg k-h

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ