mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Imran Khan <imran.f.khan@oracle.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: tj@kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH v2 1/2] kernfs: use kernfs_node specific mutex and spinlock.
Date: Tue, 4 Jan 2022 09:16:03 +1100	[thread overview]
Message-ID: <719eb5d2-680c-e596-1446-3ca8f47c3aea@oracle.com> (raw)
In-Reply-To: <YdLH6qQNxa11YmRO@kroah.com>



On 3/1/22 8:54 pm, Greg KH wrote:
> On Mon, Jan 03, 2022 at 07:45:43PM +1100, Imran Khan wrote:
>> diff --git a/include/linux/kernfs.h b/include/linux/kernfs.h
>> index 861c4f0f8a29..5ed4c9ed39af 100644
>> --- a/include/linux/kernfs.h
>> +++ b/include/linux/kernfs.h
>> @@ -164,6 +164,8 @@ struct kernfs_node {
>>  	unsigned short		flags;
>>  	umode_t			mode;
>>  	struct kernfs_iattrs	*iattr;
>> +	spinlock_t kernfs_open_node_lock;
>> +	struct mutex kernfs_open_file_mutex;
> 
> Did you just blow up the memory requirements of a system with lots of
> kobjects created?
>> We used to be able to support tens of thousands of scsi devices in a
> 32bit kernel, with this change, what is the memory difference that just
> happened?
> 
Indeed, this patch increases kernfs_node size by 36 bytes ( 28 bytes for
mutex + 4 bytes for spinlock). From current kernfs_node size of 128
bytes, this will be a ~25% increase in kobjects memory consumption.
I can replace the mutex object with a pointer to it, to bring down
the overall increase in size. Will the size change be acceptable then?

> 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.  We are seeing the launch time of some DB workloads
adversely getting affected with this contention.

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

Thanks.
 -- Imran

> thanks,
> 
> greg k-h

  reply	other threads:[~2022-01-03 22:16 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-03  8:45 [RFC PATCH v2 0/2] " Imran Khan
2022-01-03  8:45 ` [RFC PATCH v2 1/2] " Imran Khan
2022-01-03  9:54   ` Greg KH
2022-01-03 22:16     ` Imran Khan [this message]
2022-01-04  5:48       ` Imran Khan
2022-01-04  7:40       ` Greg KH
2022-01-06 20:30         ` Tejun Heo
2022-01-07 12:01           ` Imran Khan
2022-01-07 13:30             ` Greg KH
2022-01-07 21:25             ` Tejun Heo
2022-01-10 23:42               ` Imran Khan
2022-01-12 20:08                 ` Tejun Heo
2022-01-13  8:48                   ` Greg KH
2022-01-13 10:51                     ` Imran Khan
2022-01-03  8:45 ` [RFC PATCH v2 2/2] kernfs: Reduce contention around global per-fs kernfs_rwsem Imran Khan
2022-01-05  2:17   ` [kernfs] 3dd2a5f81a: INFO:trying_to_register_non-static_key kernel test robot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=719eb5d2-680c-e596-1446-3ca8f47c3aea@oracle.com \
    --to=imran.f.khan@oracle.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tj@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome