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 4B1F4C4725D for ; Fri, 12 Jan 2024 12:18:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A83EE6B007E; Fri, 12 Jan 2024 07:18:35 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A339B6B0080; Fri, 12 Jan 2024 07:18:35 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8D4B16B0083; Fri, 12 Jan 2024 07:18:35 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 7BA0E6B007E for ; Fri, 12 Jan 2024 07:18:35 -0500 (EST) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 575501C180E for ; Fri, 12 Jan 2024 12:18:35 +0000 (UTC) X-FDA: 81670562190.20.E14508E Received: from mail-lj1-f175.google.com (mail-lj1-f175.google.com [209.85.208.175]) by imf13.hostedemail.com (Postfix) with ESMTP id 5974120005 for ; Fri, 12 Jan 2024 12:18:33 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=LqXBSlvq; spf=pass (imf13.hostedemail.com: domain of urezki@gmail.com designates 209.85.208.175 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=1705061913; 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=oS2qn0GJyVpGgMF00XWbssPMomttVds4YoSmdD8QAUI=; b=l2PeuyVbJauc5qpCtMUqV6TYYmNOtkGX4OlzfoJpLMttOkVg3XuQgBtbMY+YJw2p3zCGhz MIOpEwDeR5Jj+8fDcBkUIgo2IuZ130dy7jp1MFT47fiF9dZE3omR9BQvL2j8tpLFZSYp/w LGksF40M4ket7O7ojeSp9HA543GX8CE= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=LqXBSlvq; spf=pass (imf13.hostedemail.com: domain of urezki@gmail.com designates 209.85.208.175 as permitted sender) smtp.mailfrom=urezki@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1705061913; a=rsa-sha256; cv=none; b=U2R+cbnwI0yb1CF7Asjxl4vh1QG9bgWfednDpmx5GEZ9N4F06ESpErcP9/aPvolO1DKw79 qInlESc2XgUzpODyzqnajAiHKoFvG9vouZumK1PcSMiMSmD8s5dlLIzG27lnG6CsUGwKu5 cKQEFnyoZI9K7bZcYuO/wuu1Nr2/NhA= Received: by mail-lj1-f175.google.com with SMTP id 38308e7fff4ca-2cd17a979bcso72653451fa.0 for ; Fri, 12 Jan 2024 04:18:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1705061911; x=1705666711; 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=oS2qn0GJyVpGgMF00XWbssPMomttVds4YoSmdD8QAUI=; b=LqXBSlvqQNBVMeUi5IZuJbF27+jFq+jnUaT6jpqgk4MSZ4dudZOsc2TFhvKgHFsLBa BHdF9bR29xw5+CrHk1i37ddggXhSwP5jHVcnn9aVeCe5RoFSuDwAJdKGWRQz3wIxdoDM SNj39Zo7WgsaKR1JjhHvTZyjixY9qLXwaGRVxPy7quyrhxU2pCk3ae+yIqE/ALXPnGOj pJECEEk0TYeM+x33fjLiCXY6ziOfp31Lp6RDlzJ1U4WY9BlqGaTbkpUXjHtPBP+5Rr3W Y3onUzEiztJ1zQkYMiXvOoe3CRf5IwktkfwgR1BkmV2V5sgSahLhZdk3Ed+xc71J4SN7 2V/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705061911; x=1705666711; 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=oS2qn0GJyVpGgMF00XWbssPMomttVds4YoSmdD8QAUI=; b=kJSl7LfXatqWoxgs7zIUiXLe8sBkbcOxp0nkp7lwfr1wf6Y0W4qGJ3CW3V8thpwXfi a18NyFcriggSF3qrIRxngr0+M8Vs5aXno1XQ23OGyfD2xUK28do4y49pAZ8uqUv2kz8c SHSMqa+hCuKgwkxCaj+L83IiLOpcM91UGl2eZyGz3NQ3T99IQ+W4a9Vbgkx89N3E/XMg 0OQdCxOXnZJopF5YlcmnTDs1OVRD0V3NLJFsoDTC4odat7yD83tBCc19nB5pLvL0fjD2 q1A6qJJAVe85gKbLo00rJPOarDgfGkNwxbfZ3QUZX0aWJRW993UnxnXXvtL87xHhLTc1 3Qvg== X-Gm-Message-State: AOJu0YwFAUxKdaUk5Xt579YNRGz2SEyhfDIuB0v4hUqXkZhNdIjpOYqs fxgoBsz8TeX5TX+5rBUWK3w= X-Google-Smtp-Source: AGHT+IFNYL1OyfgyDf+BH6IU8s3uCsnkAlJGEbJN8LXhms+M85RFhVMkhw3DJJPnaL0spCEIxORJyg== X-Received: by 2002:a2e:9595:0:b0:2cc:7578:3ce6 with SMTP id w21-20020a2e9595000000b002cc75783ce6mr347140ljh.10.1705061911149; Fri, 12 Jan 2024 04:18:31 -0800 (PST) Received: from pc636 (host-90-233-192-22.mobileonline.telia.com. [90.233.192.22]) by smtp.gmail.com with ESMTPSA id k38-20020a05651c062600b002cd1d9bf77dsm457803lje.81.2024.01.12.04.18.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 12 Jan 2024 04:18:30 -0800 (PST) From: Uladzislau Rezki X-Google-Original-From: Uladzislau Rezki Date: Fri, 12 Jan 2024 13:18:27 +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: 5974120005 X-Rspam-User: X-Stat-Signature: p8rgioqfcq5cc8e8x7xanmh9uknd476t X-Rspamd-Server: rspam01 X-HE-Tag: 1705061913-813578 X-HE-Meta: U2FsdGVkX1/x61H/fmoc/bL6jLsJJYqk/35LEm/2VxOm3AI8/C6YSZftNykGkPfZB6Lv5FR7dE3Js1MIv4FexZT5sjOiS/XjOnTT0gvXjpmjPZQa3eLpPgtr13Fkm7tEyebdekVw0JaJkYNYjG1pw2qMSMU5Hz92pQz6Rt+6TueEHU8FnWTNda/8MlSisGyldtnmIMVyW5ml3DzgSLMeFmSrto5ojmea54WiX7oEKi+dE+4tcjtX3fDwEbW/Z1gQfoEoa63RJOh2qUy2GRKe0rl9LiYSlKq5h1lKN+BvftjpGCm2aduutxFxbD/XkkwVVycPXaNo/Ygqcl8G35Ut1jMbXdinl9WiQAFagxnab3fr0c56+0VllUEADinVkiQD+iS8P3gFMpJHfViHdcPQwfMiQ9DWj1PbQhjhDCy81mTKd9utunvpARW8aw4kVbaXQfu5mLMCWKZlkbbSi+Dz4WYGLvhQHZg55CFfuzlZsoC+OCu4prXjQQXpVT/d7TvTRWoLbdJgVPM2/aYskaHPdr0RTES7Pd80MpeWPNwwdstquElU4t3WBkXdREGbSLxs3GVTCQmwwoRH4N8hN8BcNyr05hXHvcUwZ0tI90iLkVNM5UJ+oGGJE0aerW9S0zKTttgoTuPHoloT/D2GDlLjnqCAxdASyk2jdZe/35D1G9qt0A4yJIk8NIPAx1n0uD8bC2Gqm+BtnWAVwXKAoGNipUE5RLOOSXAuKBEspllmVD1gXlFx2KDC6eZtlkZwarYMnizy3HzBVqnEG7IWdqEaAM/NBs3JHQc2Yg7FZG/oGDZcU6vPtPV0LyylFLz0OAT8JW40HkggnU+WbyGz9eK/a54UAqinvx0Ra7f7CiX+3MawnVyIPom0RjvHDidZvJmrBhwYhuDvkosg+9KQuCWGvjNlrYW3nKKjfMJCglOPmZZj6uw2hu2V6SaQtQxtj8BNtdLFgwZwnK4rjkvloCT UP3Z9Ije LKvbWakle6gM3mXSRzph/keaC9Vl6I9f/cfw+3AUz+9dXBi2EfYkcXnu75CvrnJhx39QHBlnlFMzytcxxpmWGpRcJnD/wZcL9k8zziGlLhsbCOWzmwZeL5VHp48qj1USitspOluGehBdk1fgA7EToOtPnpYifFvxtIsy1VzyJS+NL+iwk55zs651VIPm3YsweLKXTzTq9lmwlDjmFVm2YO4VEpPpZfiM4JiIj2qjZYU5Why7x3SAnWTYOBND6L4KTRvn6zr+NilGD1aObyL9En8QcLEq0Om2urZflFbQKOqrtFqW7Bo7ib1a2y+JrOKF+rNRhjumAE0MPUK3i9+T0tTlxS09GVO1sYg5KFFxBoDq6gIqHPBOx0alvADUrMcwb//FxSXGWTCu6gL0WlFLJoPg1eC8OeFf66FmSfXk6UgOFFR90T71863619a//cM9nHN1yyGJdwbm75EeJCJp9sqwYw5Zhj6AA3taccGnkP69JkMeVWzapy1g3oRxrJpiGpP6L X-Bogosity: Ham, tests=bogofilter, spamicity=0.000001, 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 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. > > 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. 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. Thanks four looking! -- Uladzislau Rezki