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 4B15EC4829E for ; Thu, 15 Feb 2024 13:06:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CBDCD8D0006; Thu, 15 Feb 2024 08:06:16 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C6D358D0001; Thu, 15 Feb 2024 08:06:16 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AE72D8D0006; Thu, 15 Feb 2024 08:06:16 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 9AA428D0001 for ; Thu, 15 Feb 2024 08:06:16 -0500 (EST) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 5E79E41126 for ; Thu, 15 Feb 2024 13:06:16 +0000 (UTC) X-FDA: 81794061552.24.5623009 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130]) by imf22.hostedemail.com (Postfix) with ESMTP id 79E1BC0025 for ; Thu, 15 Feb 2024 13:06:12 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=wSKuannf; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=WCfKjUK6; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=wSKuannf; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=WCfKjUK6; spf=pass (imf22.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=1708002372; a=rsa-sha256; cv=none; b=V6p37Pgn6I39Ojrwa7JU9fVGG3GgWS+vPpaAgPYOOZzzz6J+V46l7WA33iioJ5Obhe3P7B c358UdQo4N5BVHN3kMiuIvFXhhcpMz1m5+knLV3Ni+QLmB2S8jop54HxKRIwCNCk1RKwIv 24kHJ09rifibLSH80Tp87B3ZjmPaojw= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=wSKuannf; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=WCfKjUK6; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=wSKuannf; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=WCfKjUK6; spf=pass (imf22.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=1708002372; 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=wqqEnx+8NJeNx4uDHqfPp5HohmNv2zWkv9TXmYpGhMk=; b=XDvGO56w85u1eqQbX4cy/jiy5fEtm7TpWEOVLjR/6eHU8HfTJwswkRmABshUeB7rXOaoNy Kf6AAMr0/nSa5f44jRIzFB3DbAADjINcA/Vaxhov7gHpkYfaAMBLHhq6y4B1EBqGU8WWgo C4I4UEfVFSoSad3ePXMY2Yf/b3C6SMs= 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 66D68221F1; Thu, 15 Feb 2024 13:06:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1708002370; 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=wqqEnx+8NJeNx4uDHqfPp5HohmNv2zWkv9TXmYpGhMk=; b=wSKuannfMnE2Un+SV6gVG9snXmdpr2prZO87oxy7yyUZZA+AS4JYyyYo0KLFdf/y3Q9qR2 LpbWMfl8DKRoYdUrnbpoBOFcHUUu1Iazdpc/xRny/ML8QM18gytBx1B94EkytOaSb+QUeR YobCLVCYBV0YXNJdx3UEIFIDsZ3C+EU= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1708002370; 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=wqqEnx+8NJeNx4uDHqfPp5HohmNv2zWkv9TXmYpGhMk=; b=WCfKjUK61HWdfZ6MCqqdy6GGwqxVG2rJ0aEm4irLhQC19wZNNFD/zawc8u9CSSUb3d2EyI L+RCu/+qzZKZsuCg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1708002370; 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=wqqEnx+8NJeNx4uDHqfPp5HohmNv2zWkv9TXmYpGhMk=; b=wSKuannfMnE2Un+SV6gVG9snXmdpr2prZO87oxy7yyUZZA+AS4JYyyYo0KLFdf/y3Q9qR2 LpbWMfl8DKRoYdUrnbpoBOFcHUUu1Iazdpc/xRny/ML8QM18gytBx1B94EkytOaSb+QUeR YobCLVCYBV0YXNJdx3UEIFIDsZ3C+EU= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1708002370; 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=wqqEnx+8NJeNx4uDHqfPp5HohmNv2zWkv9TXmYpGhMk=; b=WCfKjUK61HWdfZ6MCqqdy6GGwqxVG2rJ0aEm4irLhQC19wZNNFD/zawc8u9CSSUb3d2EyI L+RCu/+qzZKZsuCg== 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 58F2B139D0; Thu, 15 Feb 2024 13:06:10 +0000 (UTC) Received: from dovecot-director2.suse.de ([10.150.64.162]) by imap2.dmz-prg2.suse.org with ESMTPSA id 15GxFUIMzmWqFQAAn2gu4w (envelope-from ); Thu, 15 Feb 2024 13:06:10 +0000 Received: by quack3.suse.cz (Postfix, from userid 1000) id 04F1CA0809; Thu, 15 Feb 2024 14:06:01 +0100 (CET) Date: Thu, 15 Feb 2024 14:06:01 +0100 From: Jan Kara To: Chuck Lever Cc: viro@zeniv.linux.org.uk, brauner@kernel.org, jack@suse.cz, 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: <20240215130601.vmafdab57mqbaxrf@quack3> References: <170785993027.11135.8830043889278631735.stgit@91.116.238.104.host.secureserver.net> <170786028128.11135.4581426129369576567.stgit@91.116.238.104.host.secureserver.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <170786028128.11135.4581426129369576567.stgit@91.116.238.104.host.secureserver.net> X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 79E1BC0025 X-Stat-Signature: e5ttb8bmu5ckk5kkcba16hrjwhgxz1ya X-Rspam-User: X-HE-Tag: 1708002372-729242 X-HE-Meta: U2FsdGVkX1/burDhIhAAMWQk7Kdtifnn3fq3zPiSd2/qF+iOhiuFTw15RdVrdp06ho+aQQ9kS4KK63aIzMWGCMiyefLN5gmfgP2FvmPJg3NriOa6hB9ZfTkxMEfS1XNvSd/09MhJHKpEB5FI5nwgV0eubj50xhE1fd1qGEHien/d/UZShHJ+71XA0YWGmZkvnWl6wQhfVGwb3eAEqyyB4AYipWk+5Lya29gs5VDlkQdpqPVRrILU7kFvXgLIaPEMeupq2I0UX/foTXQogsyQdS0FUZONj8MlegUxeLyCL7Cs1eZhRPmlO+mHtXWwdJZ7rGLBD8qyauFcx9L0vZWuJpmbiDuRBWJDMZwBH9Tl9DFekEvbqLo1izvA8CiNFhb0DFSnyD9h6TNjwdEaIYekIexDAFnR23+8QC6NVrE0UWm+RuNlKE08l1n8wAWGrQ0CF43i92av8vxg7yLwKHeTiWx1dJcQHsGdKjQqaCqlzaF9mUrpgDdT/2xecoRVXbq+4illfqBHJcUVzHXooPCiYp43Fv+/IJDUVFb2n+EJZwjlqwqqD5iU5UnvCyMxTHMiu40Q8vwXrH5oASnhfKK3FwYmZVhkcZG20W0i6tSnVxi9hSPUZ66hK8SobfX/o4EonrzWIQUUsoDcSk8vsccYI0WzVXK6gvqXOlekla3IyWU2E0OF6IIN6liIQ4Wu9wE6udG5fFvPfOuIGShI0mEP9s5QStdzXaafMd5OutBW0szFMbI7CLF3HWs3lDtOxE4slf24pfGCoMBB7qsCcfxu2++ASWae4lgvHgNeTUcCl6sURR70Lym+I1bmBPxgwL+4Y+Lt6xBA7VMIhgxevg+w7OBIdOgIHgOysJ+X1jVqfTOlOuA6dxQnJ+FzKzjChHG7S7SwhkzIoukAMDj2KqKCgbuXF6xTSJb6Gml3W6RhbpUMOcVfprZYCyEDVFlIiXs2HV0nsKeCu3Kf/W13la6 HbAZhkbk jZ+iJM0QwTmQMCwfnsJ8VPiWffcRInE9Gg/Fe5J2kENpwIELoY7+5efk89SkwClCEgCdHU7le2gI7hrBPi6UD3+ZLh/5ZpJ2Eg2G74IXiMtM/dLefaDqHx02QX9Ke94Q+G9LURqsXuxILj8BviI8g90VEIwnQbC5oMi/EmITsp3xbSXpL47wgtF7dijBvkMgOXR3BkHDhD6EJl6LNlBeCP+GK2Pm9DSRJB82lcvYXtT68qzEJan8nM2Da45L2s6mXKUqnnYkMzaIgyEgfvUQLGgDxE3nAK64JaC6lgw48oCyEPUdSJuW9F5pfCB961sRo7wMzciU2JJRALibcbZM3iOXouwGp8BGpAK8mYfcK9TdvssITSE2vmIcoG+9uwRGY+PQId9vxwbe+JcOGq6WxgYHCZMPN5hC+POr00I/pLnqh/qL8e1sAQG5z2+rMPhZV7kPy 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 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. 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. > @@ -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? Otherwise the patch looks good to me. Honza -- Jan Kara SUSE Labs, CR