Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   Imran Khan <imran.f.khan@oracle.com>
To:     tj@kernel.org, gregkh@linuxfoundation.org, viro@zeniv.linux.org.uk
Cc:     linux-kernel@vger.kernel.org
Subject: [PATCH v2 5/5] kernfs: Replace global kernfs_open_file_mutex with hashed mutexes.
Date:   Wed,  4 May 2022 19:51:23 +1000
Message-Id: <20220504095123.295859-6-imran.f.khan@oracle.com>
In-Reply-To: <20220504095123.295859-1-imran.f.khan@oracle.com>
References: <20220504095123.295859-1-imran.f.khan@oracle.com>
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?NuCRMAcC330IPTGmg5XLEp1cq2Ezjk8g+LNz359gAcoyXJJC9V2+2RZfCCYX?=
 =?us-ascii?Q?82Odlmb2+ZtiwG/huOhJxRb8fIPCn7eqK24fDZn/TtWMNA7PqK9bfMqfFiHN?=
 =?us-ascii?Q?stz85/LFEre9jGbJTbW0Ppe8o4jPAG3AodJzyUmASSMxVESY37eh4+ct9Kuc?=
 =?us-ascii?Q?wclC6ubleNh/Wr8cGJz+jFN6yoRSYFE0rNDv84Hty9/HvvVEawKuGe8vzHby?=
 =?us-ascii?Q?buTY0U2Q6f0G40BXlQhy06loixIJ1VC8E+kZE3P6erTSbYbCHSXzI0eOzNgG?=
 =?us-ascii?Q?hjgk10NDJyPUGCaK2DHVXaBIIls8icaCSkuN87iSE8o2PH+e3m6x+EMB4//B?=
 =?us-ascii?Q?243HrzY59F9M6ACLd9mtoJHXyGWf0ATk+VzzBgzEjYOPNBwjvTPsJxxXNq2z?=
 =?us-ascii?Q?wKc171ibECLCBI5lHhAXZ9U4juWRZpGvq05OpqCH7UJWn7gUJ8bcrwCYUdDb?=
 =?us-ascii?Q?Uznk7ZBcrkL2rL50K2kylVKlbAIPTmwIdM/JRadeVZoIfn0elTbPQyuWkEEK?=
 =?us-ascii?Q?7GmGkSWsvvlIAW9sK3b2KPyaMPE7VqSZihSaJGLQ2OoG25qddRhXMIJQgx0X?=
 =?us-ascii?Q?1rPeEuMOdv+A0ba0+fPw8VUgdyURMgtImKNSHcFjMK6W484D1I2cN0m0Fe2R?=
 =?us-ascii?Q?eEGzmTKHdiKIcufC5t1a9ZjkrLdWegyae679zhGJD5eCrWNDifzLTeubqDEZ?=
 =?us-ascii?Q?g11HNjD+6DIHw2gu90Yu3hEM9h42XftzUzOTBudWIqc8YM69z+CYppEtsZBE?=
 =?us-ascii?Q?wvazkfAfWQnQ1zM2C9KSRhNqCyRS3KJBKkciyrNXWWX6tufUzQtaYqXEXtQC?=
 =?us-ascii?Q?8H2ufYnjI+l/K+UwqjeyC3HzeMJKX0qTsPRVh8JnMo8xMJ+Sr0LhYWcs5taQ?=
 =?us-ascii?Q?/Nidc29dWToJEPtgGzdIEtz1VDuS2urN9NdoNfGWSjbA77yy3nK5A8pPaGUC?=
 =?us-ascii?Q?/hOXJJ/h54rqZLkXFOP0TQLCh+uBMoBtlzOhv2MpfKj6LChtgQp14WV+Dm8K?=
 =?us-ascii?Q?xMxmn2mepeMwl9CJy7J5MPh0TpD7SfBS932DCB4WiPrQUv3xxGK0p5ln4Z2l?=
 =?us-ascii?Q?pLLMpJpqS2tlOdQdJL2ROPN+S14kqjqsm3jGPm7qARd1vTb/vh39bGytkdP0?=
 =?us-ascii?Q?7i84WUFobrffjhuONAEOxszIpOlcWUdcm7bGQP2R507WFalvSj6Yy2EXIEJA?=
 =?us-ascii?Q?X6NjJ4k33RzNcCRDQkFDJzXa1Ugutu/pduadY8V7i67Y7Lamc+pxLybhHS/j?=
 =?us-ascii?Q?2TfGM9jUsfxWTGfTQObDxmnJkHi085zhY0xAo+V4aVs5/+As+qQYxh9kN0x2?=
 =?us-ascii?Q?o+SMECRVwgPEao1FtpN0wBBc4aGm/sews4CmB1m0YTxDWja7cnxXN/nLriTf?=
 =?us-ascii?Q?GmDMLAj/uLKoBLTRzzF1W2IsAVlHXEHSvi/md74D9PZNF9G0Gxv/s8BTftc1?=
 =?us-ascii?Q?fSglcAnzV1sscoLJxYloe8jM07OzEcVThRBIFg08fCV0E4ZCIq4s1rK/0nfv?=
 =?us-ascii?Q?eYX4EvEWjqTJ4XJrVP7DwTwTetuNrxt3unpsZ1JKUdOIGcjLRfYLebkEIqdY?=
 =?us-ascii?Q?CprUPYU1ooekH/xzxhMcSLpN63xvSS8U971re14yT2lYipMgo9G0EUnRpu1Y?=
 =?us-ascii?Q?HCtTgoABWQOUqTZPcjDZ09Ti/ajyXojeiEbaISa2E+rwnzI2LtXkHLsRWuzX?=
 =?us-ascii?Q?Qyred7MGTwDKCUFDXnLnOCUWOKNuXslNbQUEfYVpGr2K8NDa3HIUaqtPXnIP?=
 =?us-ascii?Q?RhEhvjFyrDQjooyyLXbEKZjcmxTjAOQ=3D?=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 16505ffa-a799-431f-85b9-08da2db3b5e5
X-MS-Exchange-CrossTenant-AuthSource: CO1PR10MB4468.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 May 2022 09:51:50.4210
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: ddRO4lY2rVuk8Dot9NA387LY8zykC+v0iAqjpXQ12PTgAocqmTOzJJeK0B4J4rdh2Koc66kby6qREHRXPSkuIQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLAPR10MB4899
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.486,18.0.858
 definitions=2022-05-04_03:2022-05-02,2022-05-04 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 phishscore=0
 mlxlogscore=999 mlxscore=0 spamscore=0 suspectscore=0 bulkscore=0
 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2202240000 definitions=main-2205040065
X-Proofpoint-GUID: bmILUFcD8A7FTwpgaP9BhshWULU0_bAe
X-Proofpoint-ORIG-GUID: bmILUFcD8A7FTwpgaP9BhshWULU0_bAe
X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,SPF_HELO_NONE,
        SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no
        version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

In current kernfs design a single mutex, kernfs_open_file_mutex, protects
the list of kernfs_open_file instances corresponding to a sysfs attribute.
So even if different tasks are opening or closing different sysfs files
they can contend on osq_lock of this mutex. The contention is more apparent
in large scale systems with few hundred CPUs where most of the CPUs have
running tasks that are opening, accessing or closing sysfs files at any
point of time.

Using hashed mutexes in place of a single global mutex, can significantly
reduce contention around global mutex and hence can provide better
scalability. Moreover as these hashed mutexes are not part of kernfs_node
objects we will not see any singnificant change in memory utilization of
kernfs based file systems like sysfs, cgroupfs etc.

Modify interface introduced in previous patch to make use of hashed
mutexes. Use kernfs_node address as hashing key.

Signed-off-by: Imran Khan <imran.f.khan@oracle.com>
---
 fs/kernfs/file.c            | 17 ++---------
 fs/kernfs/kernfs-internal.h |  4 +++
 fs/kernfs/mount.c           | 19 +++++++++++++
 include/linux/kernfs.h      | 57 +++++++++++++++++++++++++++++++++++++
 4 files changed, 83 insertions(+), 14 deletions(-)

diff --git a/fs/kernfs/file.c b/fs/kernfs/file.c
index 7a60074ec0a0..946a4a8d7e32 100644
--- a/fs/kernfs/file.c
+++ b/fs/kernfs/file.c
@@ -18,19 +18,6 @@
 
 #include "kernfs-internal.h"
 
-/*
- * There's one kernfs_open_file for each open file and one kernfs_open_node
- * for each kernfs_node with one or more open files.
- *
- * kernfs_node->attr.open points to kernfs_open_node.  attr.open is
- * RCU protected.
- *
- * filp->private_data points to seq_file whose ->private points to
- * kernfs_open_file.  kernfs_open_files are chained at
- * kernfs_open_node->files, which is protected by kernfs_open_file_mutex.
- */
-static DEFINE_MUTEX(kernfs_open_file_mutex);
-
 struct kernfs_open_node {
 	struct rcu_head		rcu_head;
 	atomic_t		event;
@@ -51,7 +38,9 @@ static LLIST_HEAD(kernfs_notify_list);
 
 static inline struct mutex *kernfs_open_file_mutex_ptr(struct kernfs_node *kn)
 {
-	return &kernfs_open_file_mutex;
+	int idx = hash_ptr(kn, NR_KERNFS_LOCK_BITS);
+
+	return &kernfs_locks->open_file_mutex[idx];
 }
 
 static inline struct mutex *kernfs_open_file_mutex_lock(struct kernfs_node *kn)
diff --git a/fs/kernfs/kernfs-internal.h b/fs/kernfs/kernfs-internal.h
index eeaa779b929c..3ae214d02d44 100644
--- a/fs/kernfs/kernfs-internal.h
+++ b/fs/kernfs/kernfs-internal.h
@@ -164,4 +164,8 @@ void kernfs_drain_open_files(struct kernfs_node *kn);
  */
 extern const struct inode_operations kernfs_symlink_iops;
 
+/*
+ * kernfs locks
+ */
+extern struct kernfs_global_locks *kernfs_locks;
 #endif	/* __KERNFS_INTERNAL_H */
diff --git a/fs/kernfs/mount.c b/fs/kernfs/mount.c
index cfa79715fc1a..d0859f72d2d6 100644
--- a/fs/kernfs/mount.c
+++ b/fs/kernfs/mount.c
@@ -20,6 +20,7 @@
 #include "kernfs-internal.h"
 
 struct kmem_cache *kernfs_node_cache, *kernfs_iattrs_cache;
+struct kernfs_global_locks *kernfs_locks;
 
 static int kernfs_sop_show_options(struct seq_file *sf, struct dentry *dentry)
 {
@@ -387,6 +388,22 @@ void kernfs_kill_sb(struct super_block *sb)
 	kfree(info);
 }
 
+static void __init kernfs_mutex_init(void)
+{
+	int count;
+
+	for (count = 0; count < NR_KERNFS_LOCKS; count++)
+		mutex_init(&kernfs_locks->open_file_mutex[count]);
+}
+
+static void __init kernfs_lock_init(void)
+{
+	kernfs_locks = kmalloc(sizeof(struct kernfs_global_locks), GFP_KERNEL);
+	WARN_ON(!kernfs_locks);
+
+	kernfs_mutex_init();
+}
+
 void __init kernfs_init(void)
 {
 	kernfs_node_cache = kmem_cache_create("kernfs_node_cache",
@@ -397,4 +414,6 @@ void __init kernfs_init(void)
 	kernfs_iattrs_cache  = kmem_cache_create("kernfs_iattrs_cache",
 					      sizeof(struct kernfs_iattrs),
 					      0, SLAB_PANIC, NULL);
+
+	kernfs_lock_init();
 }
diff --git a/include/linux/kernfs.h b/include/linux/kernfs.h
index 2dd9c8df0f4f..13e703f615f7 100644
--- a/include/linux/kernfs.h
+++ b/include/linux/kernfs.h
@@ -18,6 +18,7 @@
 #include <linux/uidgid.h>
 #include <linux/wait.h>
 #include <linux/rwsem.h>
+#include <linux/cache.h>
 
 struct file;
 struct dentry;
@@ -34,6 +35,62 @@ struct kernfs_fs_context;
 struct kernfs_open_node;
 struct kernfs_iattrs;
 
+/*
+ * NR_KERNFS_LOCK_BITS determines size (NR_KERNFS_LOCKS) of hash
+ * table of locks.
+ * Having a small hash table would impact scalability, since
+ * more and more kernfs_node objects will end up using same lock
+ * and having a very large hash table would waste memory.
+ *
+ * At the moment size of hash table of locks is being set based on
+ * the number of CPUs as follows:
+ *
+ * NR_CPU      NR_KERNFS_LOCK_BITS      NR_KERNFS_LOCKS
+ *   1                  1                       2
+ *  2-3                 2                       4
+ *  4-7                 4                       16
+ *  8-15                6                       64
+ *  16-31               8                       256
+ *  32 and more         10                      1024
+ *
+ * The above relation between NR_CPU and number of locks is based
+ * on some internal experimentation which involved booting qemu
+ * with different values of smp, performing some sysfs operations
+ * on all CPUs and observing how increase in number of locks impacts
+ * completion time of these sysfs operations on each CPU.
+ */
+#ifdef CONFIG_SMP
+#define NR_KERNFS_LOCK_BITS (2 * (ilog2(NR_CPUS < 32 ? NR_CPUS : 32)))
+#else
+#define NR_KERNFS_LOCK_BITS     1
+#endif
+
+#define NR_KERNFS_LOCKS     (1 << NR_KERNFS_LOCK_BITS)
+
+/*
+ * There's one kernfs_open_file for each open file and one kernfs_open_node
+ * for each kernfs_node with one or more open files.
+ *
+ * filp->private_data points to seq_file whose ->private points to
+ * kernfs_open_file.
+ *
+ * kernfs_open_files are chained at kernfs_open_node->files, which is
+ * protected by kernfs_global_locks.open_file_mutex[i].
+ *
+ * To reduce possible contention in sysfs access, arising due to single
+ * locks, use an array of locks (e.g. open_file_mutex) and use kernfs_node
+ * object address as hash keys to get the index of these locks.
+ *
+ * Hashed mutexes are safe to use here because operations using these don't
+ * rely on global exclusion.
+ *
+ * In future we intend to replace other global locks with hashed ones as well.
+ * kernfs_global_locks acts as a holder for all such hash tables.
+ */
+struct kernfs_global_locks {
+	struct mutex open_file_mutex[NR_KERNFS_LOCKS];
+};
+
 enum kernfs_node_type {
 	KERNFS_DIR		= 0x0001,
 	KERNFS_FILE		= 0x0002,
-- 
2.30.2