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 8C8F7C47DB3 for ; Thu, 18 Jan 2024 18:15:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0E0906B00A4; Thu, 18 Jan 2024 13:15:21 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 090C26B00A5; Thu, 18 Jan 2024 13:15:21 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E9A8E6B00A6; Thu, 18 Jan 2024 13:15: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 DBA416B00A4 for ; Thu, 18 Jan 2024 13:15:20 -0500 (EST) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id AE206140DBE for ; Thu, 18 Jan 2024 18:15:20 +0000 (UTC) X-FDA: 81693234000.15.45F6FB3 Received: from mail-lf1-f41.google.com (mail-lf1-f41.google.com [209.85.167.41]) by imf06.hostedemail.com (Postfix) with ESMTP id BC383180013 for ; Thu, 18 Jan 2024 18:15:18 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=UsrIxnYk; spf=pass (imf06.hostedemail.com: domain of urezki@gmail.com designates 209.85.167.41 as permitted sender) smtp.mailfrom=urezki@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1705601718; 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=OboWUpBalDVf1FYx0j2uJTiF97MBbBNmetCopQ/pijc=; b=ghuC7ayvPjuqPqATpm4ji6hdmG5UDGKl+IJg6f7XJDLAlrfoNYx0VxDaLOsnYqgnnc4eih 2GdsI59pvibYM0zvAQFudMQ2+vOz6feenrnuIjKnC7pFLpRsVbtom/39xI+K2u4xc+XRSu QDDQYsL0ZBGPF5oPb6HMjI83SKnVpBo= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1705601718; a=rsa-sha256; cv=none; b=iOfzugSSZ8tXA6l9g/dNAbYe2BT/hJTBf8mlmpqr2dsQ3hD79JcTiReMQ4hlMZn5Z6zGGi et9a7qA0OHgND3n14s27pP4Z3yXoT3fZT+onpf0uT3/mZ/9jfIAyVEm0YPBqUdmtMPIxkR TcOHtlI4Xf/46NaeJ0koIivTmEdi6kI= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=UsrIxnYk; spf=pass (imf06.hostedemail.com: domain of urezki@gmail.com designates 209.85.167.41 as permitted sender) smtp.mailfrom=urezki@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-lf1-f41.google.com with SMTP id 2adb3069b0e04-50e7e55c0f6so15412986e87.0 for ; Thu, 18 Jan 2024 10:15:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1705601717; x=1706206517; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:date:from:from:to:cc:subject:date:message-id:reply-to; bh=OboWUpBalDVf1FYx0j2uJTiF97MBbBNmetCopQ/pijc=; b=UsrIxnYkJkM2HDozGmAUQzq0tk0nYWyAXhtv1R9duraSS6ptOfHQ5g6yZmvmDnvBnX OeGRkj3drmKCTNSElaUxFAeR8Kz09hQDN4Lhn8mIZsjKE1zjfLo7c4u1uFZ+noYW/zyn cEbVSZU8+/oW8jsGwpopnG0t67b2f7ZGPNHBubROcFVMcgM2sPGoG3VlahB9IwSExVWg giFKzwGXydtji+LPHSNYSiTdzA4ZkNB7iKVXFLT8/2Z2QgQ8NYXPd5ZyZ2UIiPsTmGQd xpMfbSuOi3HZeBceGGwbDjY58iEIicf3A70v74XqyIEjBrgAzsNdzMCPWcZJbR2hCCYc X3wQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705601717; x=1706206517; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:date:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=OboWUpBalDVf1FYx0j2uJTiF97MBbBNmetCopQ/pijc=; b=mC7VKAJ8v5SxxCBndK/4TLGeJEbuaVRv4/jOt1DEn5t6weujpElLYlXQZh1mK7ZeBK 5hq9IiAboYikPAv7WNgDCKks6OS2goGL/4T8eGb0Dy5GxvApRWbPhMkYYg1UfTJp59DQ sSvsctNs5n3eAvr2zKcgn+/OrUzBJuT7HDlJDQ15c5FNUSTpa+R4ErxuAa8VSuL/KmsE spVV1bjTP3/GSFgxlLcEk+p4kwXQv+RmtZ1KDrSt8UC7TgpOatmpwp4sxOD33jjcaIOL CQZbTCwJhAPlbpQtOb2FS3Teo8JvkYL4iqspy7r1uxrh7pCjF5IegSz4UEcjslUAEv+X eMHg== X-Gm-Message-State: AOJu0YxKal8T0OJoszBe8l8JUlRKK55rvqgHrKMjZQpK51FOIpkCZK+p hjZPzWyacAw3rPLVip90Nsc4IISTsCsCF93jTseBdVgRNmFDXj/E X-Google-Smtp-Source: AGHT+IH1dl8jzJ2Xn42wXNlKGfwKO7wFKYaTY9es9z2dJTN8R+/MkyJ2Hkbls78VZ0LhdfYZgCZBWQ== X-Received: by 2002:ac2:4c42:0:b0:50e:bb33:840b with SMTP id o2-20020ac24c42000000b0050ebb33840bmr19210lfk.99.1705601716671; Thu, 18 Jan 2024 10:15:16 -0800 (PST) Received: from pc636 (host-90-235-20-191.mobileonline.telia.com. [90.235.20.191]) by smtp.gmail.com with ESMTPSA id p15-20020a056512234f00b0050e7ec49881sm714234lfu.21.2024.01.18.10.15.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 18 Jan 2024 10:15:16 -0800 (PST) From: Uladzislau Rezki X-Google-Original-From: Uladzislau Rezki Date: Thu, 18 Jan 2024 19:15:13 +0100 To: Dave Chinner Cc: Uladzislau Rezki , 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-Queue-Id: BC383180013 X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: zk9nqtey7c6pphm73pt4ip5d5o1zbgob X-HE-Tag: 1705601718-795521 X-HE-Meta: U2FsdGVkX19PvQFHHwJuaPxZ8r8ywYtlubMz/C06vWgi7DebhZrLectERV7OE4YfeijRkp3CSV3M97cSOidwr0SHlPNEhvp0r33kc3xAmNDrsEgbBLele41xIn77JPV4SB/ImEwXiX/DCWUOFrI2Jbjk6DdXIUpKnnkpGBnVHTiVqIZo/xTiVLveCl/trFza5457sxcOTCMLACeSqhSTW8oBDBNZ6fRkzEo7jE6N9E25fJtT458Eb+hDP3a6AIA6J9P/kptYhbqKVUaGQr8sVsVVNCyIW1LX6BcZybn54yDPN2MpvkQBHTWmzYpR1NTR0BlxO2sMg1TN/36NxN50Qu6IF27nZdl8A/VRw0yHc8jljQbX8qWQ1HOL18tfswgk/lfcbpr9+F3R45QPkqB6pFhlOf44q5F1ss6xnPb3JSmE4BBFy/pf0Z36KZiR2Ya457bEZhXsY4I1lK4q2cUvF/KH9rVj1HLD88G4wjXN579gIQrULKpj4PGJX6kAR0CmWKxoFVKOhHvvIuEMRkb11JW+5VVnNFw+gnZXrD3b2myMHK7pOVqZ5testlAEwkIMUxCDXUOfbx01QI3Ikaqq6h5Y/BCO0DrB5EvpT/iDLL73C74MRcpyUkpDMxkUgqwNYojYzef3pjNzIFARJ3qPSQ25BZZawj4qgIzFon7IRZlZ3BWSukydw0UgKX6ESYHk8vvcPcITPGYNy8iXatocHXaDCI57N/8R7vMFx2dBw06cIWgfb9dY7wc7BbSBDo7xrk94V2uvWnU4Sktto/yYBNAtPTOQvo1tY1RfDiQp4+GovRzqfup9++Cn1b5Ib1kKjm53m8Yo36L42ItB0+yhAaJ9t7Luxjj/r9vADGSghR72DC0yFcJzQwjnXsuJ3VSNr8JKcs7zm27P4FmcapcfQH/pwwF45gaza1BHqUTCcBGEKL17ZBTCJde9bh1qFnXvBqMoFG6elZsDcAB9t4C EJrqI2/Q 8ZvtfATpv9v5j0ItMHBID9th0AUJBl0WiD24/0Xcrhw2jvdxzOlKn7oFkaQEjTqITzu+g9y/GhcFtK9FoDJbwtitP+xmevgkrF9YQiDClq3+SJC8/TeAl57/GplUvTapmlnGbqEOVeprY7S7ADUytLOFuRMlX5C8joC5XNJS4rVrI39E9K2DajOV3S1V+zXcdV6+R0uW8P/n5SSN9+VxOy/NohxR4gWXy9YxM00m4ucxnwbVNATNqFhYtTK46rqCd+5enKWjHQonSBBkkuM+ptat96wH3gWnTYCwBoBoX5ESjkNVC7DP999+dS5tmqJ2J3Adg8deR+iwBDnyeg69lZbqWplZnuhfvXCM49xSd6fZALa0M646Rgn2dFs1MnPdLIm5AlK6V/h/TiIk5SOh+ahubmCMmbWw08+k1fPLt8MdLYHBj3wyZkvu59tBAJEHs+xe4y4F27kd0g+qwS0y/YMisIQ4e/c0iLw9OYy7TIRs7oMEr0Ma6lV+Bee0rcWnckq41 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 Wed, Jan 17, 2024 at 09:12:26AM +1100, Dave Chinner wrote: > 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. > As i pointed earlier, i will have a look at it. > > > > 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. > I mean the following: 1. first = llist_del_all(&example); 2. last = llist_reverse_order(first); 4. va = __llist_del_first(first); /* * "example" might not be empty, use the batch. Otherwise * we loose the entries "example" pointed to. */ 3. llist_add_batch(first, last, &example); -- Uladzislau Rezki