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 69AC2C54798 for ; Thu, 7 Mar 2024 20:11:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 047746B0297; Thu, 7 Mar 2024 15:11:21 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id F39E36B0298; Thu, 7 Mar 2024 15:11:20 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E01986B0299; Thu, 7 Mar 2024 15:11:20 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id C82006B0297 for ; Thu, 7 Mar 2024 15:11:20 -0500 (EST) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id AA200C07CB for ; Thu, 7 Mar 2024 20:11:20 +0000 (UTC) X-FDA: 81871337520.06.912FBDB Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by imf01.hostedemail.com (Postfix) with ESMTP id 797CF4000A for ; Thu, 7 Mar 2024 20:11:18 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=SdNPdVcq; spf=pass (imf01.hostedemail.com: domain of akpm@linux-foundation.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1709842279; 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=fCvL6fbeKTOs1E3CWgQdqAS2CWjZtpr19Nxp2XeyqPo=; b=kalHy+cCdPafWDUQdk3mTjh14xX7IFbPdPAPWakGQq8QHpaWFN+kGprz1QAz8sx9zVXKPV 4OYVIaGASnGdY1aTecM5jlPFMk+yjQxvfTrZ4YfXoL+kWWrvPnljYeTZpo9inhHeL8ELj5 bBN+s36PXsV6eLsuvZ6GliCgYj6bCmw= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=SdNPdVcq; spf=pass (imf01.hostedemail.com: domain of akpm@linux-foundation.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1709842279; a=rsa-sha256; cv=none; b=hJQMgWW7bH37kuj80P1eHJwkMn8rIXx7KwNmL29zZWzmR2WwatL0dXUqFJ+IQWoVc7TAV9 HvoxK6HCZlf0UTnZ1fOkBUIStrZ+DTs2FljQHCRCuhZGhpzf5k9Q8uO4JQUZQOtKSBahpB nHnMX7pal+BO6sPxge6xwA9Y+kVUJ/E= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id CE7BECE250C; Thu, 7 Mar 2024 20:11:14 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A7751C433C7; Thu, 7 Mar 2024 20:11:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1709842274; bh=B6mfEbg7m6R6+7MIeFP+NGCTEGpLaAV/oieLgTsxJJg=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=SdNPdVcqPXz6WFeB8AcTxbuot3VsDMqNuXo9pWXMDBY+e7UjrNYXofmz6G33eO8js 0vmqVGIwlHF7Q752/q21DZhsgjO5e5uEJnuYRxDJ0clsrt2Hflx4VhGX4mscTvLgEF hLL3jWHamjjmzSJyz4rLUtusAUEN7GmKHklWX6Ls= Date: Thu, 7 Mar 2024 12:11:13 -0800 From: Andrew Morton To: rulinhuang Cc: urezki@gmail.com, bhe@redhat.com, colin.king@intel.com, hch@infradead.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, lstoakes@gmail.com, tianyou.li@intel.com, tim.c.chen@intel.com, wangyang.guo@intel.com, zhiguo.zhou@intel.com Subject: Re: [PATCH v8] mm/vmalloc: Eliminated the lock contention from twice to once Message-Id: <20240307121113.16cc480515195f1fe945bbac@linux-foundation.org> In-Reply-To: <20240307021440.64967-1-rulin.huang@intel.com> References: <20240307021440.64967-1-rulin.huang@intel.com> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 797CF4000A X-Rspam-User: X-Stat-Signature: 3pijb9ubuoaiuu3zgfau8z1r9cn51my9 X-Rspamd-Server: rspam01 X-HE-Tag: 1709842278-870384 X-HE-Meta: U2FsdGVkX1/2CTn/FTjq/Mcc3jcuIr9BqfkmQDOWG+UKiBorF4TX9nsqz8lqYfxhliV4mGbWTzVlJGKka82LSBCkfXMZEBXBx/svjv6wNbwh3G9POCRgnZiEbHH4azmmznpzzwdafmpUn2QIGpULtPPRiJh/cBWjzFh6sbIszhbuzwPUt1h1jQ6zUUpmf/qylI0ShiggZZ67Q7jfkmVHxW/7xs6wZtfLOdCxJlkR39E0xvExHYIIhWDdhKIXoKuUvLHNdRm9w50SmCkReoY5LbZEB14s+ZdJuFBrOtSZ6jk+MWGE1asepYR//kc56M2GmNvM8W9bmi0Gu1xzg3WbVGzk8sVhRgtjwE6tp4LmrVJsa2p70/IhEWxwGqO1+6RiBKGegg2vmq19N7G4Prh37E5QyYRYs70geRkA6R6Jyb1jeUL0Mzjceqa3widSFWBX1R6UNh3bgl61N4UhgqGAEICm1Pe0ckrqRn5RHK5uzqPpdoQFq+bISBzWfvzInRej+EuRED3JjODZ4SBMel/XtXGu0P5S/6q2dt+XSajB0YauYZe7SwLj9yvYelhRq/kjlQWo2phQd1X/Hc8+OLzhnOgwd6UEJnsSkrwRqWAVYB91iKT/MTWn95FtqDi1RLzoTIGLSjMK4SNf08vLsyj/cN+pfojEgJ9IqtAKyLQyKljotIinvX7TYO3QMXJKBwhCtuhSobW9NE6v6fx8m2XYNAiUAaS0LgvUnATgmDT9I6/gnOCmTs4ygqnubBe7ZaP9Wh5tDg/udUmrDWzTxb1uc+UjaFFEtXBsyWySWjo9n3lc3pyUJE6TvaV7nyZkoVafGrmRmNAPYM3ApDZw0A9Ycw1VIaZOMIWv8Q27k2YR8hTXCMn2VQfN5j9L6ztBvAk9YiXnWDshDvRGVX3j6/5ZF6bAsG3igaZDhLUe03TPHQshyUsx6CxvES+9bMOdYhqw9Hw+5OAF9E9ugZjsW15 rflTIEq+ TOW7Z4ICIrOaQaJCLVhofqEJz07d4nkK0dOlA8n3GB6UUUttlPAHXnbyhxD5WBpb5RxtgZD7OCBuetK9sAO9bppnZLDNYUqoTouJ0qMseA8JrqD4En4ADP2floudD7ymVVO9Hc9jW+SG1L1qsgsdX3wDCHKB4Gxi7fbmEryoMt9RPVeUgsiyk1tol5waZv0FmxWBAUNHUfjTPSidEDmSz4ypnMHAmv41+Ni00ZaN/eqWDRlRQnwrkYUc68xh2sJJzdUf0WXCfVksF1U1E92wbr9WEBw== X-Bogosity: Ham, tests=bogofilter, spamicity=0.012615, 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 Wed, 6 Mar 2024 21:14:40 -0500 rulinhuang wrote: > When allocating a new memory area where the mapping address range is > known, it is observed that the vmap_node->busy.lock is acquired twice. > > The first acquisition occurs in the alloc_vmap_area() function when > inserting the vm area into the vm mapping red-black tree. The second > acquisition occurs in the setup_vmalloc_vm() function when updating the > properties of the vm, such as flags and address, etc. > > Combine these two operations together in alloc_vmap_area(), which > improves scalability when the vmap_node->busy.lock is contended. > By doing so, the need to acquire the lock twice can also be eliminated > to once. > > With the above change, tested on intel sapphire rapids > platform(224 vcpu), a 4% performance improvement is > gained on stress-ng/pthread(https://github.com/ColinIanKing/stress-ng), > which is the stress test of thread creations. > Thanks. We're late in -rc7 so I'll queue this up for merging in the next merge window.