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 589CBC47077 for ; Tue, 16 Jan 2024 22:12:33 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C15486B00A5; Tue, 16 Jan 2024 17:12:32 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id BC6826B00A8; Tue, 16 Jan 2024 17:12:32 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A66746B00AB; Tue, 16 Jan 2024 17:12:32 -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 92A666B00A5 for ; Tue, 16 Jan 2024 17:12:32 -0500 (EST) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 63681120668 for ; Tue, 16 Jan 2024 22:12:32 +0000 (UTC) X-FDA: 81686574144.09.76692A6 Received: from mail-pf1-f178.google.com (mail-pf1-f178.google.com [209.85.210.178]) by imf20.hostedemail.com (Postfix) with ESMTP id 839BF1C0007 for ; Tue, 16 Jan 2024 22:12:30 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=fromorbit-com.20230601.gappssmtp.com header.s=20230601 header.b=vxF9HS0g; dmarc=pass (policy=quarantine) header.from=fromorbit.com; spf=pass (imf20.hostedemail.com: domain of david@fromorbit.com designates 209.85.210.178 as permitted sender) smtp.mailfrom=david@fromorbit.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1705443150; 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=z31N7igtmEX2QoESZM8Ds3APvcIeb/dGLKwEtxypi1c=; b=o/t7mQHnfuQjAlCYMTUNY6bb9rBbqqc2+BqAH/mXvoQ1mgBFQEMazKl8PNTRJUjrLCsdDr yJdjdqamh8hA6BXCm16y/OwmIu5p0JklEHjre9ECEryysc0SEUxsCFQPgoBhzF+yfvXQbx PCF6rQtfEq26OZ4Y+VyR6DBg0DXi7ws= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=fromorbit-com.20230601.gappssmtp.com header.s=20230601 header.b=vxF9HS0g; dmarc=pass (policy=quarantine) header.from=fromorbit.com; spf=pass (imf20.hostedemail.com: domain of david@fromorbit.com designates 209.85.210.178 as permitted sender) smtp.mailfrom=david@fromorbit.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1705443150; a=rsa-sha256; cv=none; b=KdAW9yGcJdrLgwj7eRoJ15IvG0xg3q8gd7lGxCU6Pn9RC0HSYm7tBTYbH7WKSWRcsFUkGV +z+HvPafWrrNAds2nGDu+4zivleDm3INBcNSFyl6ZCUQ6Ik+dA6IPcZc0VcflbSn2U9gck /T47BY/k2NrEsb9Leg941CL81/1zN48= Received: by mail-pf1-f178.google.com with SMTP id d2e1a72fcca58-6d9bbf71bc8so5259758b3a.1 for ; Tue, 16 Jan 2024 14:12:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fromorbit-com.20230601.gappssmtp.com; s=20230601; t=1705443149; x=1706047949; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=z31N7igtmEX2QoESZM8Ds3APvcIeb/dGLKwEtxypi1c=; b=vxF9HS0gzKE2EtM7Jza1dQd3XX79Em9RvsAEqnlgDt+X7CLAaTwWWO1x1FkGhIp8bP cAx6gqhG5nMSjrkZtvsHh9C9MR17giADQ+xwXD+1Y2l9mKk69barROBVIEULLQUsAQkN XZUrGaDNsX0mrnIirzkJY0Edo9NOWUVg5IomW/CHLYS6pTznXQHHVN1T004vYVFzF6Xk SrxVVTCmZKPNeq9TEhtReqtneLvLia2U5IL7S+OtlQeOCgi5NU3Y6cj/4iNIlkuREyWL SwldToRl+l5rSa6Q6IEs/N6naTVUE9J6OtBVOsN5RJ+CtlFQ/c1837BlafVwhAUDonfa tVQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705443149; x=1706047949; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=z31N7igtmEX2QoESZM8Ds3APvcIeb/dGLKwEtxypi1c=; b=HOU1Kj7gFKD9NguMSXU18pY6jDkDP7rNlAJfbnNoyqgJhlYPbT6i8xw4TQWEU6hrQL aMOjQPhXy3a5LN+Mmdhpg9aPQkjnhaAiexBa4n8ztu01Jd6PY7ih0K+ya8bNcwmwn0tV a66BKHNbMlUc3JGLDt1bsuI5DRHFxkM3kZMbTQJ/BHeP93a/TunT3OG6entdIwaDHzya gImnbHxZxzI3JuPE5wxKj5hdQWY2M3DcG8xygKa0uCWFBI6w8iDv8vpoGReGsBPs9uV2 5uCpcvhPQI7caI5K0R5Nno6Ng9WHIO1ea0hrduI3WB08fG3sBnmEYEcx4CMmzOb4g2ee i3qg== X-Gm-Message-State: AOJu0YxP75AF6K001hqVbM3q5LZ/12dYRqi7DRwCfhGJyTtJIT3Ou/cz /KBTo0kAXdqtlAKTSCR68IuvE2zqoWzK/JzrBH8+vnFyt18= X-Google-Smtp-Source: AGHT+IFHH2qeXyHnecx/FBEzzK9UJHHFn2J6URo64iIU3pTkPlUE9TMKkBuNJaDzrjFtZ4+L1L9+Sw== X-Received: by 2002:a05:6a00:93aa:b0:6db:c92:edc8 with SMTP id ka42-20020a056a0093aa00b006db0c92edc8mr5775089pfb.5.1705443149344; Tue, 16 Jan 2024 14:12:29 -0800 (PST) Received: from dread.disaster.area (pa49-180-249-6.pa.nsw.optusnet.com.au. [49.180.249.6]) by smtp.gmail.com with ESMTPSA id p42-20020a056a000a2a00b006d9b345092dsm71495pfh.156.2024.01.16.14.12.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 16 Jan 2024 14:12:28 -0800 (PST) Received: from dave by dread.disaster.area with local (Exim 4.96) (envelope-from ) id 1rPrfW-00BJds-1K; Wed, 17 Jan 2024 09:12:26 +1100 Date: Wed, 17 Jan 2024 09:12:26 +1100 From: Dave Chinner To: Uladzislau Rezki Cc: linux-mm@kvack.org, Andrew Morton , LKML , Baoquan He , Lorenzo Stoakes , Christoph Hellwig , Matthew Wilcox , "Liam R . Howlett" , "Paul E . McKenney" , Joel Fernandes , Oleksiy Avramchenko Subject: Re: [PATCH v3 07/11] mm: vmalloc: Offload free_vmap_area_lock lock Message-ID: References: <20240102184633.748113-1-urezki@gmail.com> <20240102184633.748113-8-urezki@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 839BF1C0007 X-Stat-Signature: kocctpbgmiqiffyokrxqsqk8bj9rkth6 X-Rspam-User: X-HE-Tag: 1705443150-781512 X-HE-Meta: U2FsdGVkX182yKIXPVkIOwnm7S9x9S2QGg5OE+GOzVtkTe3QLA6NjvfkI9omzI3LklWzi5BL3FIEF2J0J3pCFpvOIQY2YnBbFZxdoDpwAhBvaeVqeLPPPDnKKDjDY4CSkT+7kJkF2Qt7NRISuB9lnwaTg3MQ3ZWW6wY7YT4NYF28Scx21MWBbs7CZFQtBnfKArpiF+IEesIpVbaWTc2Di81+8AmsKJsVa5DAf00V+rwiWi+eSIdRmLHmsSRg7Ih7nvjD/8/2fw+wgCOpelWokUdIjEavX2kvBmHOCBloZdkbpwVZ56QnjThYflmJdU3WGPNxhRMKOzEpebFq0+0Oys13h4vwxrb887xjll0ul8CG6zXV2cZwjV0K3xT8TyiL8mdlEFCcS1EG/nKLZfAAsbp7i4Ca1DQ4Jey5yYSUjIPFm4DsMvfUcxDGGiunp9bbeGb7X203ZdL7ZZlWPv0Zrl8swwmUg6UdSLq6NrKzYeUoKp9U64L7CwnOCVm/o5ATxEAwG6EBkXX3KrCMgdNiRZ4TwOZGE/AB2YTEOgJxqxCImKswCsM6CSUB5ZHZxmy+SGumTJuzzmzgBJ2T2LX4BGMujqrv5AEJCaOq+xgXK16ANArZsnCuS2vDX1y3chYMKvCi2EPPvDuvJCzNAZVjoq71LdI8WDHBRTtZZEQSYP4DOyoWaBBa+biyljmDSN5uZUQwalERMsKpLwPSBenIEaO4w9vHC4MrgZF8XEEq7SGBldrYYgV1ZLhtWSx1z0w9N4vI70r7DWBOQPZ0nln4L4uCnDkFKjRuSfT9a6oq0rJ74T0WKU4kXAW7rnrGaC00LUDpZjfsgBIAI/+ZyKtY8/QqD8fM+uig1Kway7xRpPrUBUcVMoBMq5tRs7jeuuj+5nVW6ICX3LPqkOqBOBKiIz2Rk5+IaivZyF92hoTmpUHbFg6+A/OxYp26tbY2beq9uch1xnDLUKc5LLxlzWY Hx26a0C4 oz3pJURuWQb8D082UWacoGSH06OYrMIXuVwIGIJe1gSiZR+y8vEhz+404/VKnTy0jSGR7K7IJZ7cs9kGPyMvPcmV11OERdnnbNfVSPnbqkIak66MZRfi8ZIOx40/vnM626zDokp4sKpjCzt1/SLLC2hl0PONT/xHbcWTD4uJdiRdIIdDvyZIcvAj26TofKcXREtoT33bUTanaVFrTenCsSw8YxGjfxAXr0Ykh7F7LcAF9HmdH8fho79cOHiu/khfVnI8iTqozHmu8v34xK+AHHV2sDZD9JJdelpVht5T/zq86tc5T3j1EO2QMd+tH+IwpY7qLuA1Q/RyQ+KFG0N8HC8YdAcUGaSYz4KcEQH2mI2tjf+njeSqEupcdXIPIRwE4CoIGfMNxbu69+DGhSvVaNxamksJ6fVykk9ygC01DL7TRjla/OPRbojjTfkFa+Obpa7nHMS9WnjnmHkTKr+z9JSeXDD/8Nf/Q/pZY4fPgEISdgs0FEGLrGdf5dErR99lFjVxYdzvUT7eyylXUFC3ehb3vYSYIatAe7XTWCrCCUJ80GGdqvSlRwPr4TqfUd5WQ0SuY 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 Fri, Jan 12, 2024 at 01:18:27PM +0100, Uladzislau Rezki wrote: > On Fri, Jan 12, 2024 at 07:37:36AM +1100, Dave Chinner wrote: > > On Thu, Jan 11, 2024 at 04:54:48PM +0100, Uladzislau Rezki wrote: > > > On Thu, Jan 11, 2024 at 08:02:16PM +1100, Dave Chinner wrote: > > > > On Tue, Jan 02, 2024 at 07:46:29PM +0100, Uladzislau Rezki (Sony) wrote: > > > > > Concurrent access to a global vmap space is a bottle-neck. > > > > > We can simulate a high contention by running a vmalloc test > > > > > suite. > > > > > > > > > > To address it, introduce an effective vmap node logic. Each > > > > > node behaves as independent entity. When a node is accessed > > > > > it serves a request directly(if possible) from its pool. > > > > > > > > > > This model has a size based pool for requests, i.e. pools are > > > > > serialized and populated based on object size and real demand. > > > > > A maximum object size that pool can handle is set to 256 pages. > > > > > > > > > > This technique reduces a pressure on the global vmap lock. > > > > > > > > > > Signed-off-by: Uladzislau Rezki (Sony) > > > > > > > > Why not use a llist for this? That gets rid of the need for a > > > > new pool_lock altogether... > > > > > > > Initially i used the llist. I have changed it because i keep track > > > of objects per a pool to decay it later. I do not find these locks > > > as contented one therefore i did not think much. > > > > Ok. I've used llist and an atomic counter to track the list length > > in the past. > > > > But is the list length even necessary? It seems to me that it is > > only used by the shrinker to determine how many objects are on the > > lists for scanning, and I'm not sure that's entirely necessary given > > the way the current global shrinker works (i.e. completely unfair to > > low numbered nodes due to scan loop start bias). > > > I use the length to decay pools by certain percentage, currently it is > 25%, so i need to know number of objects. It is done in the purge path. > As for shrinker, once it hits us we drain pools entirely. Why does purge need to be different to shrinking? But, regardless, you can still use llist with an atomic counter to do this - there is no need for a spin lock at all. > > > Anyway, i will have a look at this to see if llist is easy to go with > > > or not. If so i will send out a separate patch. > > > > Sounds good, it was just something that crossed my mind given the > > pattern of "producer adds single items, consumer detaches entire > > list, processes it and reattaches remainder" is a perfect match for > > the llist structure. > > > The llist_del_first() has to be serialized. For this purpose a per-cpu > pool would work or kind of "in_use" atomic that protects concurrent > removing. So don't use llist_del_first(). > If we detach entire llist, then we need to keep track of last node > to add it later as a "batch" to already existing/populated list. Why? I haven't see any need for ordering these lists which would requiring strict tail-add ordered semantics. Cheers, Dave. -- Dave Chinner david@fromorbit.com