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 1B68CC5478C for ; Fri, 23 Feb 2024 13:06:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7C6886B0072; Fri, 23 Feb 2024 08:06:52 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 776B16B0074; Fri, 23 Feb 2024 08:06:52 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 63ED86B0075; Fri, 23 Feb 2024 08:06:52 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 53DDB6B0072 for ; Fri, 23 Feb 2024 08:06:52 -0500 (EST) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 255AA1409B8 for ; Fri, 23 Feb 2024 13:06:52 +0000 (UTC) X-FDA: 81823093464.23.B0FDD0D Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.15]) by imf25.hostedemail.com (Postfix) with ESMTP id DDC8BA000A for ; Fri, 23 Feb 2024 13:06:49 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=VqVmcLFr; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf25.hostedemail.com: domain of rulin.huang@intel.com designates 192.198.163.15 as permitted sender) smtp.mailfrom=rulin.huang@intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1708693610; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=5LaaG9lKqPjlJ6lGmAv1BTUe4R/0FIRcG2M1z3DuBv4=; b=HwcT4pOtbOwIsPvMdrOkpYUCZj0JqqEcXWwaFxdxqTBMvGgWDT3PsyR8oqkVBvr8G5l9k3 DPV6A5n42yQqDPHnwQV7WZZgLgkzVHEym5y8JMWagJcdtOWVEjJhWZxdheB3DrGgf07bvm DakQM4aRqOobl6s8S77auaki3/ZIiDo= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=VqVmcLFr; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf25.hostedemail.com: domain of rulin.huang@intel.com designates 192.198.163.15 as permitted sender) smtp.mailfrom=rulin.huang@intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1708693610; a=rsa-sha256; cv=none; b=FQkdIpPx4njBWJABeM7HLDImhzg1zaiOuCZOYNv+8Snpus8MiMV0MlTBo0lP7a5oNqL/67 27c+i9SQ038P0LGNSscxsObpeTWttepXngScK1ZJmoMk2RQtostbu4iM1XL1+uVl/MEosH tVBFXogox1i3IASofIpq71NT5vjAAn8= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1708693610; x=1740229610; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=vrHViwPtfViEodYrYu27uDWOfGFSmxsgqGqcy7hiZeE=; b=VqVmcLFraOcy+/sR2m//W2buY1mmrZzuNUfHEdjGl7swtGIwyghlb1kI s2XF1yxW7oYRKo8PywSvhNOnv6zJ9YZzmsKrG3zPfCu6JCBhFgJW55i+T 51h1kqmuN5Kdk4iHGaERpex8KrtRJ0rQO+2m82vnPvIk8Wn5aNabaTECl xqs1xZ2I9+01rml10761speDyw7pqgOyjs1r8MZvcrhYQT6pm92rwK0ZR vRQK3LPSn2FDAjJ8Tnq8Vl95D7ka559gkuGo+j08aI/TAcvIM7S5PE4xk e81WM4ONzVoSZjWNWUFcuXJ+zR52lmHNlFffw+L/sQu7la3qbvRXNv5xR Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10992"; a="3164263" X-IronPort-AV: E=Sophos;i="6.06,180,1705392000"; d="scan'208";a="3164263" Received: from fmviesa009.fm.intel.com ([10.60.135.149]) by fmvoesa109.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Feb 2024 05:06:48 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.06,180,1705392000"; d="scan'208";a="5859032" Received: from linux-pnp-server-09.sh.intel.com ([10.239.176.190]) by fmviesa009.fm.intel.com with ESMTP; 23 Feb 2024 05:06:45 -0800 From: rulinhuang To: urezki@gmail.com, bhe@redhat.com Cc: colin.king@intel.com, hch@infradead.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, lstoakes@gmail.com, rulin.huang@intel.com, tianyou.li@intel.com, tim.c.chen@intel.com, wangyang.guo@intel.com, zhiguo.zhou@intel.com Subject: Re: [PATCH v3] mm/vmalloc: lock contention optimization under multi-threading Date: Fri, 23 Feb 2024 08:09:25 -0500 Message-ID: <20240223130946.112890-1-rulin.huang@intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: DDC8BA000A X-Stat-Signature: upxq7wpxh3sne74qzmn7fgmq1kfne688 X-Rspam-User: X-HE-Tag: 1708693609-954843 X-HE-Meta: U2FsdGVkX1+WXs0QYjNeYtNbpnm+cl3KCdfes/Ufn+AehfxJtNzGjPEXhUBKrezZidqx2l2nQH5zRcnwWx+prIEDsU/L0Ikh4whx4TkeZzX5lqPgvmBi851UL01qRXd6wsvkMVXy9AdB6RGlCTDEXit1yz2vEEFBKburU7ACwDVcicLk0BFRnc6sXAMWo7n00GlgtUd07+Ur2M+fZO0QTSQa5ECd8bQQbPK2mk7Je59T59pi3b0dH9bihL0UqhRDhUN+Ebu6fNsLuBS9T6W/7jtzMJgDrNgXjYgPxZIhMNHc9BJEVAecIC1V1e2ztsxWPbeZ+fhqLFdnFj61QyRiwohyttOQRLBhZLucSZTy2fXBrIsEQClBB8R5qu5ldjI992A/HItuP/9YwJ4cFsM4v1WiHa/1RHnsD2AvFFQDKbPZy973LFEUm0KK/8K0WFPGhXfTxJlo7V6wGNHIcvqiEry66/2NoaEqaEPIGkTOzB/h0+zfTCz8spb9oI14wPnX9rRPrYVtZs9nW1/yLjY9M3O36uPNupAscvzybNdatGHbjdC4fJB/ypbwQxv0iu9N2F+MwObSUF5hjtD7vtOKuAQgsutpB4QZLdRCOq522jnESn93q/NRyT7djK3YR4zxypljJI6bQ2uBTxdQqVhccPiQPml7SlkUL/D2SQ/tMgFcqMChFg1RKNz3ejctQHgs3t/+piOuhp4TYB81bufvJRwNZKaBMF+kESVY+6xOs3EVPpDBpoOafrcb7MLzHl+xSg6GByE7AtTYK0KPyrqFVEYS5W6LBDYIseLjr1vEqDKzuclnQ8N1dtL5OmwqYx8x3+w9gB7LTKH5ZKNaxX/xL+XEI3pqcCBKARUnsAt13l9uooUFEtFpBoXHEISF1GxCReLxMlBQX5duqkj5f5WumP3BdIqUZsBW2JppGT/NpTKaxgCxCj/xi4vxLWYF4Cq3WgzNxP3yrma4M5SgIXf zAWz//ex EoV4dm969XUyv8quY7Q1GvivYjdMG8T1TAT/IL4b484vFeun5y2pwwiTlPJ8Nb3/q+vaXbG909e6F/FOyjGO0RvwUz/hsdq0NgHU3ixjVRlw7pfM/RC74r3getyCcOkT8AhcO81aMgYn1ahqCUrtEDPee3mkiijz7NKC7zs1Mw9vmUhA= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000002, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: > > Hello, Rulinhuang! > > > Hi Uladzislau and Andrew, we have rebased it(Patch v4) on branch > > mm-unstable and remeasured it. Could you kindly help confirm if this > > is the right base to work on? > > Compared to the previous result at kernel v6.7 with a 5% performance > > gain on intel icelake(160 vcpu), we only had a 0.6% with this commit > > base. But we think our modification still has some significance. On > > the one hand, this does reduce a critical section. On the other hand, > > we have a 4% performance gain on intel sapphire rapids(224 vcpu), > > which suggests more performance improvement would likely be achieved > > when the core count of processors increases to hundreds or even > > thousands. > > Thank you again for your comments. > > > According to the patch that was a correct rebase. Right a small delta on your > 160 CPUs is because of removing a contention. As for bigger systems it is > bigger impact, like you point here on your 224 vcpu results where you see %4 > perf improvement. > > So we should fix it. But the way how it is fixed is not optimal from my point of > view, because the patch that is in question spreads the internals from > alloc_vmap_area(), like inserting busy area, across many parts now. > > -- > Uladzislau Rezki Our modifications in patch 5 not only achieve the original effect, but also cancel the split of alloc_vmap_area()and setup_vmalloc_vm() is placed without lock and lengthen the critical section. Without splitting alloc_vmap_area(), putting setup_vmalloc_vm() directly into it is all we can think of. Regarding Baoquan’s changes, we think that: We prefer put setup_vmalloc_vm() function not placed inside the critical section and it is no need to lengthen the critical section. We prefer use judging (vm_data) rather than ((!(va_flags & VMAP_RAM) && vm), and it is enough to deetermine the conditions for assignment. The change seem to be wandering about the judgment of va_flags. Hi Uladzislau, could you please let us know if you have any better suggestions on the modification scheme? Thank you for your advice!