From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 90AC3C4829E for ; Thu, 15 Feb 2024 14:02:58 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F1A0A8D0013; Thu, 15 Feb 2024 09:02:57 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id ECA698D0001; Thu, 15 Feb 2024 09:02:57 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D925E8D0013; Thu, 15 Feb 2024 09:02:57 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id CA4A78D0001 for ; Thu, 15 Feb 2024 09:02:57 -0500 (EST) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 41ECA1A113B for ; Thu, 15 Feb 2024 14:02:57 +0000 (UTC) X-FDA: 81794204394.19.9464E8D Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130]) by imf10.hostedemail.com (Postfix) with ESMTP id 25BE1C0040 for ; Thu, 15 Feb 2024 14:02:50 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=KYf2HRwe; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b="d4ja/xq9"; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=K+vr4KtS; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=BXrZpsO8; spf=pass (imf10.hostedemail.com: domain of jack@suse.cz designates 195.135.223.130 as permitted sender) smtp.mailfrom=jack@suse.cz; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1708005771; a=rsa-sha256; cv=none; b=FT191c7nQD70zOoTuMJwHMwDPeIgkGv3rYIWUEnaWdezIYvdMHeAcmv2z34RgmfokNtqYw 7u2xTZwyQcBbKQVDcZG9BDEJ6qiyUiyHfvlhiBVcWp59yHTt9VJpLFgosn5ReoO4qJY/fd HIcV4ZjMxBkYY12XxP7sYl47cRAuzfk= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=KYf2HRwe; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b="d4ja/xq9"; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=K+vr4KtS; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=BXrZpsO8; spf=pass (imf10.hostedemail.com: domain of jack@suse.cz designates 195.135.223.130 as permitted sender) smtp.mailfrom=jack@suse.cz; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1708005771; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=+usnLuQgIopfcd+tk9ECF+6CmkhAWjNe58jT5Yn3I4M=; b=ASW23/MHIHpoe41iFJy9Ke0vqFzw2OE2KnDpFz5tB+DgMzQ6FeCKYfH9NmY0gduOT8rf+P qoArDU1iVuGs+hzLz8bFGyOMG/326j1I0iw7fPj3U6bo6HSzAg8GQehvonATFSGncZABp5 L1BuKzZvEOpp9+RHIrG0rBRazznkHnM= Received: from imap2.dmz-prg2.suse.org (imap2.dmz-prg2.suse.org [IPv6:2a07:de40:b281:104:10:150:64:98]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id D22BF22219; Thu, 15 Feb 2024 14:02:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1708005769; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=+usnLuQgIopfcd+tk9ECF+6CmkhAWjNe58jT5Yn3I4M=; b=KYf2HRweXaH6U7DUyxQzr9yV3tnZ8xJDeDFmk3ThE8hwV3MjbVIGObM//8ht/HW+FNP3zA yvfJjpp3K34LA7U8B39LlRJa1pahuTCz8EGoA2YF11fjF30fU4sIKeRzMEQu1ZelTv8o35 HuC82eZ9Rh/qdWvpChOgqR42gDPtbxE= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1708005769; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=+usnLuQgIopfcd+tk9ECF+6CmkhAWjNe58jT5Yn3I4M=; b=d4ja/xq9FH/CTdWU8n2zFUqV1U+ZHqUa+SJVjLTSWtOz5+id1PDy389mJtITZh//ne3GKk p/B7vG+mQGzMarAg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1708005768; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=+usnLuQgIopfcd+tk9ECF+6CmkhAWjNe58jT5Yn3I4M=; b=K+vr4KtSAP11iadW6esi0FmFl1KVp+MSxbYbhrevxWRLhh9BDOCG8Tzof3RIfZffsixPkh pmzqYT/DI2vLlpWWcXOmoQ5Sn+BtWXUtbmHJVvDVu2zHpKCm88yX62+ZAq8EsCL6p12cZZ dMW8cW+ELNTEfnpfmqW8q+fgUTCLfz0= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1708005768; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=+usnLuQgIopfcd+tk9ECF+6CmkhAWjNe58jT5Yn3I4M=; b=BXrZpsO8nFOHBYsC48MTTeu2ZgnEm7XqUpvLEaMEwRSZbz0ipQd/O2j3HrybE2Y2yiJhzR P4BjJfwbv6LHMfAA== Received: from imap2.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap2.dmz-prg2.suse.org (Postfix) with ESMTPS id C5C591346A; Thu, 15 Feb 2024 14:02:48 +0000 (UTC) Received: from dovecot-director2.suse.de ([10.150.64.162]) by imap2.dmz-prg2.suse.org with ESMTPSA id IxNHMIgZzmV2IgAAn2gu4w (envelope-from ); Thu, 15 Feb 2024 14:02:48 +0000 Received: by quack3.suse.cz (Postfix, from userid 1000) id 6CACFA0809; Thu, 15 Feb 2024 15:02:44 +0100 (CET) Date: Thu, 15 Feb 2024 15:02:44 +0100 From: Jan Kara To: Chuck Lever Cc: Jan Kara , Chuck Lever , viro@zeniv.linux.org.uk, brauner@kernel.org, hughd@google.com, akpm@linux-foundation.org, Liam.Howlett@oracle.com, oliver.sang@intel.com, feng.tang@intel.com, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, maple-tree@lists.infradead.org, linux-mm@kvack.org, lkp@intel.com Subject: Re: [PATCH RFC 6/7] libfs: Convert simple directory offsets to use a Maple Tree Message-ID: <20240215140244.njd5emd6ikbjfj27@quack3> References: <170785993027.11135.8830043889278631735.stgit@91.116.238.104.host.secureserver.net> <170786028128.11135.4581426129369576567.stgit@91.116.238.104.host.secureserver.net> <20240215130601.vmafdab57mqbaxrf@quack3> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 25BE1C0040 X-Stat-Signature: sy6gob1o5o48kgph8oi5fjwmef7d59wz X-Rspam-User: X-HE-Tag: 1708005770-17185 X-HE-Meta: U2FsdGVkX1+E+d66Bj0TljiEpGb/qDUooOwHLgMq9ZXbJciSNEODOAyoGLVaF+FMgmW5a7ySPMMED3Y7Us8A45kBrIIdFzka7Ilvs3VXzYQ/58Kw5BUkztSuf4yW9bKBCxlbpqjjuAEVz0L9YVt0pOA9V9qhiWPzfubEWdRcFWkrowbowFTfjPqUsZApG2y66WDSyM5wMdReNMJanZXB/6dIIA+a3kiHV00+ixO6EofylsNayYB3bcB0imE/8PO21XQEGzW+tzA3sbZhgmhjKXEgnjtkdjMRNcxJ9HEZkB40uviJDRQ8xzPIqsD3JAFTZx2pmLa9dHOugkm2GOAHTJCVI3euof59WNqQ7jJObNZnqLXQMgX/WSQUz9TgCRFa9hurj2DWyga5BSOuQCneQH2TLR+SpZO3HdutKXKqP2USYa/9lDxns2VPHKvM34RlwGE0cr8PbvbmJJ+wpyFMCU7Rb//WlfJ711aFSgXCv3CciZ/ev2F9ir25cS2qop5O93r2TDkLXQ+0D/R4R4nSOjFE5QEzDWIKdV5D6GYRFlQQQDOqOQUeN23ykNTddO6nX4/D3+NN2wTZ6nKsvCmvoLbCEi8bL0QKg/nTYszp//kpbGXS1vG30/wW5F+XFQb8IVm3Zw7ni09JT4WxYqRlzTlamRUa85vWvyDd/PLWVAZDB69maG8TYEMGMX2Z9yZ0Iyr4RqYlp0BBPEqMvHRYuyyOBkIlxFS4KyNc5QGQZ0FhDNf5ZgceAND7hvOX8rabnmDDQsoYh9MxIVm8NgSAQ5DFCIr0FiKyxG38fMHhBOkRDk19PH43+4CHZcmi22WogBUaFvrFLyFxeIL+yc9hugJiSU5pJc175hGtdKEJklnB1DoyY+56UMy85afjLrP8VwaxFSv2TNs0AXsxuGAQrtMTs9zBton8JaRbWg9XuMatxtgalN1r8oIeutomJPGEjqlAhpZZyTj0Pc77B5E kvFbGElB bM9YpDrCQvWyO/qMhcCp7nazcdcBBOAVJNCspWEBSfRONVjwNWsNa9iuO2zgxIfkI3ZPnjN6gMoclLitA96BUbB0IsfCVMWQ7F/gZgb7qnTxQjyEA6CoEHza2rVsTM9wPfOFy1eow9NAqEOJ04W2qlm37a0mxFHFXfrimd+JoMx9XHQwHgZNuT57QyPqjZgJS/J101stSklwBq7byencb6XkcCE/9gf62K9w7bPW6RJc7lQ097ZuKYHJ6ixEE15+lVjSoWXcyoyeTXEHxWssC+tG6qy5In5e2vgmZS9txSwi5N+8kvu2uDX6fCLSESXL//HsDwwQSn4Yw7Dj0Ja7ifdBfv5YemgxHZ3IWBrXEBam3W8mRuh08S5WAmcDI/l5QlKNOx1gwp/IQ89SIt68cbgxQe8jJ+z3wTNAAPpVkBNLzycZUvUArAl5sSZjGj0dq+6rC X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Thu 15-02-24 08:45:33, Chuck Lever wrote: > On Thu, Feb 15, 2024 at 02:06:01PM +0100, Jan Kara wrote: > > On Tue 13-02-24 16:38:01, Chuck Lever wrote: > > > From: Chuck Lever > > > > > > Test robot reports: > > > > kernel test robot noticed a -19.0% regression of aim9.disk_src.ops_per_sec on: > > > > > > > > commit: a2e459555c5f9da3e619b7e47a63f98574dc75f1 ("shmem: stable directory offsets") > > > > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master > > > > > > Feng Tang further clarifies that: > > > > ... the new simple_offset_add() > > > > called by shmem_mknod() brings extra cost related with slab, > > > > specifically the 'radix_tree_node', which cause the regression. > > > > > > Willy's analysis is that, over time, the test workload causes > > > xa_alloc_cyclic() to fragment the underlying SLAB cache. > > > > > > This patch replaces the offset_ctx's xarray with a Maple Tree in the > > > hope that Maple Tree's dense node mode will handle this scenario > > > more scalably. > > > > > > In addition, we can widen the directory offset to an unsigned long > > > everywhere. > > > > > > Suggested-by: Matthew Wilcox > > > Reported-by: kernel test robot > > > Closes: https://lore.kernel.org/oe-lkp/202309081306.3ecb3734-oliver.sang@intel.com > > > Signed-off-by: Chuck Lever > > > > OK, but this will need the performance numbers. > > Yes, I totally concur. The point of this posting was to get some > early review and start the ball rolling. > > Actually we expect roughly the same performance numbers now. "Dense > node" support in Maple Tree is supposed to be the real win, but > I'm not sure it's ready yet. > > > > Otherwise we have no idea > > whether this is worth it or not. Maybe you can ask Oliver Sang? Usually > > 0-day guys are quite helpful. > > Oliver and Feng were copied on this series. > > > > > @@ -330,9 +329,9 @@ int simple_offset_empty(struct dentry *dentry) > > > if (!inode || !S_ISDIR(inode->i_mode)) > > > return ret; > > > > > > - index = 2; > > > + index = DIR_OFFSET_MIN; > > > > This bit should go into the simple_offset_empty() patch... > > > > > @@ -434,15 +433,15 @@ static loff_t offset_dir_llseek(struct file *file, loff_t offset, int whence) > > > > > > /* In this case, ->private_data is protected by f_pos_lock */ > > > file->private_data = NULL; > > > - return vfs_setpos(file, offset, U32_MAX); > > > + return vfs_setpos(file, offset, MAX_LFS_FILESIZE); > > ^^^ > > Why this? It is ULONG_MAX << PAGE_SHIFT on 32-bit so that doesn't seem > > quite right? Why not use ULONG_MAX here directly? > > I initially changed U32_MAX to ULONG_MAX, but for some reason, the > length checking in vfs_setpos() fails. There is probably a sign > extension thing happening here that I don't understand. Right. loff_t is signed (long long). So I think you should make the 'offset' be long instead of unsigned long and allow values 0..LONG_MAX? Then you can pass LONG_MAX here. You potentially loose half of the usable offsets on 32-bit userspace with 64-bit file offsets but who cares I guess? Honza -- Jan Kara SUSE Labs, CR