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 B95E1C4828D for ; Wed, 7 Feb 2024 09:25:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 20AA66B0074; Wed, 7 Feb 2024 04:25:08 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 194556B0075; Wed, 7 Feb 2024 04:25:08 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 034976B0078; Wed, 7 Feb 2024 04:25:07 -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 E173C6B0074 for ; Wed, 7 Feb 2024 04:25:07 -0500 (EST) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id AC730A1000 for ; Wed, 7 Feb 2024 09:25:07 +0000 (UTC) X-FDA: 81764473854.22.880CBA9 Received: from mail-lf1-f51.google.com (mail-lf1-f51.google.com [209.85.167.51]) by imf28.hostedemail.com (Postfix) with ESMTP id 87C3EC000F for ; Wed, 7 Feb 2024 09:25:05 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=D1QUFfcG; spf=pass (imf28.hostedemail.com: domain of urezki@gmail.com designates 209.85.167.51 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=1707297905; 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=yF3gre0TO7JfQnBIzArzEHplr6VLfvwUebv5ae+w5FA=; b=g4qJEa2Zrssk0Z0u8tg6rdUH4NoluWX9Yd3Hb/4MRJEtCf8C9kzlU1ve42Ys88iGugieYi ahJ+ys4Uzaqo+6J5qyVwG3Zd4w7k8EIiXbxXUB+CamtGJWbpmYTjdvkOuptw8uuQUPKieV UP/MalH5s+tify7v0+PEKPMSgPsUp40= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1707297905; a=rsa-sha256; cv=none; b=isWpio7XXFQpl+ymSaxOEuPMu0MGSVPq790oNy7V0FNUC17mbDNHh+vBXo2TIpB9cmHLyb GEC3771TfBQE1MDdtW43kCKtu+SCfvub3TUmBfhX4zSu2SojwxqFFqLP2IqBckAKrFPwes 9yfPKgblPexaDmc43maKtyDEAGpCwyI= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=D1QUFfcG; spf=pass (imf28.hostedemail.com: domain of urezki@gmail.com designates 209.85.167.51 as permitted sender) smtp.mailfrom=urezki@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-lf1-f51.google.com with SMTP id 2adb3069b0e04-5114b1e8819so572176e87.1 for ; Wed, 07 Feb 2024 01:25:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1707297904; x=1707902704; 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=yF3gre0TO7JfQnBIzArzEHplr6VLfvwUebv5ae+w5FA=; b=D1QUFfcG585ToL3uUSLjgrOlxLAxb+ZNFG2/3Pbap20wJQXLLNb0ffIamkRwZPdHue AU9uQZE+ZcpITmRb82mv5NgS6eeF75KF3NRCvY+gyFnYeVrfIOAmLRwTxgDKpOauyR0f bwU5NmUeo65fIR0LcNgp/kq0Q2X0oeuwTpTsBvSvj7EYDcUHb+RJftt2aKxQYs/KQL3y GfHSOpmFg36QdnrOIoJxwHtBRIytNRix6CVSpuAmZT4DF5dX6ra4NN3zL1cmW1dqaZvD VBrgBazGsWu0W2Cw/EapsfO09epHMXUofstZVSlzFyc3zmm80SZ3kVwmeEGbWnIt2Yj2 RaWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707297904; x=1707902704; 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=yF3gre0TO7JfQnBIzArzEHplr6VLfvwUebv5ae+w5FA=; b=YYF2koHQR8sHeSIUW7TuBCSJMZnT3uh8tTmv++WkWSWR21ZH7I4NbkMXWim/JCvrr/ vzwkHnfA8o1pWXO8ue+rLVjxqHBRyrwaRdi0Ay8OguhnHxdhRo8BboWmWrum0FCtvjNe 7CB6W6AcEgYsZ25La3W4J0fUcpAK+agF7jn6p9ZtCgTpltnrXSMIOSN4kwzZu7SA2G9Q HtvsAEqef71qEdvx1tv3+LArmG0jM0efkqbC2Gd7wCySS9xj0QP6SYm0en4f8kd8qs+l Z095RIJfqtqh+nrjXrhMFD2+JyKvr0luGatT8Vte/BAjzyjXuuRf0rdWLMKlOXzCfhmc sPrw== X-Forwarded-Encrypted: i=1; AJvYcCU2TaiORaEMS8FC4EVZseVazYc1DY76X4L3tb2HZ+l2/wZCrSgy3sN9B5c1gzZuLLNNne8v01SvlmgLBcY0GbBwmB4= X-Gm-Message-State: AOJu0Yz6KYoWZ++CVy5nel+DYR/HpKY71sWDiHjuEx96jdz+WWah/s08 1SZzLjqI9LydhtnMVakyOK2t+h4uue2hfHNeJJeZDtsyo8LvQF7i X-Google-Smtp-Source: AGHT+IETe2MT6aV7GlxmGa61KUBpsJJwTVyDPwgfxDI0q97DvvmY0jd3JR8xqGMzVNltAs4DYoW38Q== X-Received: by 2002:a05:6512:32ab:b0:511:627e:36cd with SMTP id q11-20020a05651232ab00b00511627e36cdmr2301780lfe.24.1707297903277; Wed, 07 Feb 2024 01:25:03 -0800 (PST) X-Forwarded-Encrypted: i=1; AJvYcCUO2/ik0M9x1I1dXAPi4GJLZX067x6AmN5+jfeNW8mb93T9FLwBavnsC4SuICQ7FxP2v8u5ber/z2+y+NxgSGmuUVKtorRXmnZp+zWXPiCBvlAmhL33m5E5i2bg7tTHr/exMC1btoVz0z3ZQ6NP7eBEQovE9cTjuq8C6FvNoVTj0FWmh+C7YTP16vC0eQKyq0YMmLKCAZhEAgaYkW3sFR+hd66REcbfTRO0DrT0/KrLFuaeqzt5U1rXIHxbA5D95bOjzdnc4AwIlQr6i/U34tTT9y9jn7FsX7Hj/C9e Received: from pc636 (host-90-233-221-0.mobileonline.telia.com. [90.233.221.0]) by smtp.gmail.com with ESMTPSA id j15-20020ac2550f000000b005114d74f9casm114756lfk.150.2024.02.07.01.25.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 07 Feb 2024 01:25:02 -0800 (PST) From: Uladzislau Rezki X-Google-Original-From: Uladzislau Rezki Date: Wed, 7 Feb 2024 10:24:59 +0100 To: rulinhuang Cc: akpm@linux-foundation.org, urezki@gmail.com, hch@infradead.org, lstoakes@gmail.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, tim.c.chen@intel.com, colin.king@intel.com, zhiguo.zhou@intel.com Subject: Re: [PATCH] mm/vmalloc: lock contention optimization under multi-threading Message-ID: References: <20240207033059.1565623-1-rulin.huang@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240207033059.1565623-1-rulin.huang@intel.com> X-Stat-Signature: w9gqcptou3cx11zk6phqk4e6s3bt5k66 X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 87C3EC000F X-Rspam-User: X-HE-Tag: 1707297905-142155 X-HE-Meta: U2FsdGVkX18fQ1F+zOtlFaTOIqpohhPBXltt+bG8GdgD1YlG/vYYJQLf5vh95b1P68n5XeMZ6AoE97wa3kv3Rpeu63gZi8ycbAqtzaETTqJcygQ3DFtowFp9OKetOdelDsU8Q4KOS8YxkjN5/DKvmKRCLcVTqhhZy6MG6NBijfQ1T0vcWpIQjfN079FDKj9/eR+ExK2PzansEh0Y5nnpAKpMHAtIfZJEVeUkHvKIS+qF3aVBV+cBuV8vnfZKQnMaT62g4te5H5RhuDi9bmHa4MgiIpULPOQObAC9TuMstKtt5ifajnc668WsDqWj+GWgIPGmtRlfgGHrQXotCHJNKwkURh7p9pV6S2+05Jse7/rx4pH+21di9m69tBR+Bx41393V3+TqGnVrpzMI+hSigm8Y70oKhg5+pC5nQWyBIjyitnwS8Ym1z1+M/YWWaHRlcO+OjJaZUPj51hB/HhU7cwVmbwsZx3qWSdVQ5VSyOkCJuuxUC8zjEllh1y8qTc5B9queEttxx/+HOsUzeYNdsBh3sHe7d+KEMyNrthfiH328IpBtl07I4JLaFyZbW8WYLBHFKIp4uA0Rhm9mQ+cp8JkSsM4gkOPjucu6PYQSx3R8p6xoxAbt6Hhix8va1SsDLsgezunVCBSr3nrm7Sj9VS7J4lU7c/XgYn0vwAxpZlAb6U4cA9/Qc+PnCFhKExwKVN1JOCA65SBryaIGqBCsLHskDc3TDQExeth2e9nCGVrnG+2wM3HKxuuSPpiiC7yEVHOp9sea/iqlHE4lUuCIoVrWf73Nn/LUyGAK/31U6MG3UVbyWU2jXG8KR2vbDv0OxzeYVTTA/X71hNvE0WMQ1VEzyB9Y1aSymnnhKD68D75a2TBANeVb+KMQPwS2JGsulyd09HqUxNfVIsHrMk39mvk4MrrMxJ2f/45E6SEPgnsPvSyE77TkkSz8PJLAYf3EGgmUDiOYW/1oddn1xw0 GPqLofel vcFCt3WtMGuOG/RiD3u7+wC5SQLGMYZsDNCzf4KSVvO8u6Lke2+YeupF9XDse2pbJXbwwZ2NUdy6YwVRHQQsq1pty6/A+7HMrF2nK+/y84Rz2tWpxsnDw/IyogFkFMYgjlEV+u6PyOpqZgxUUdIahFlHQZ1N8qc8xlC7mLKtQqyMZPg+IrcJPn3p2u4xVyqqu+ZeDl8mFctL0eDqlZXI3k8EZ5yalgd4XT0ghR6C5wGi4IyyeB283r1ZuYQDsS6TjzcYXbu7XBdKJGdPIy14oNl3ioMA+QeHs8lPell2uJxuAXLvKIdQDxi4/jY5xQGWU5OxnfX0LPOmj4scXKZFjBxpYU3zTW5iZtiJBF69NCs66T5ej/D+1zeId/+n21t0/PP5wCdei4AJJby7hpiGXlnK0tZXBrXRkxJDaBSCnsnlwaeawQ0JZa0eV+lEBooolIiMVDa51XAMm617z8bfu+67uhSIdW/251q5R 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 Tue, Feb 06, 2024 at 10:30:59PM -0500, rulinhuang wrote: > When allocating a new memory area where the mapping address range is > known, it is observed that the vmap_area 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_area lock is contended. By doing so, > the need to acquire the lock twice can also be eliminated. > With the above change, tested on intel icelake platform(160 vcpu, kernel > v6.7), a 6% performance improvement and a 7% reduction in overall > spinlock hotspot are gained on > stress-ng/pthread(https://github.com/ColinIanKing/stress-ng), which is > the stress test of thread creations. > > Reviewed-by: "Chen, Tim C" > Reviewed-by: "King, Colin" > Signed-off-by: rulinhuang > --- > mm/vmalloc.c | 31 +++++++++++++++---------------- > 1 file changed, 15 insertions(+), 16 deletions(-) > > diff --git a/mm/vmalloc.c b/mm/vmalloc.c > index d12a17fc0c171..3b1f616e8ecf0 100644 > --- a/mm/vmalloc.c > +++ b/mm/vmalloc.c > @@ -1577,13 +1577,13 @@ preload_this_cpu_lock(spinlock_t *lock, gfp_t gfp_mask, int node) > > /* > * Allocate a region of KVA of the specified size and alignment, within the > - * vstart and vend. > + * vstart and vend. If vm is passed in, the two will also be bound. > */ > static struct vmap_area *alloc_vmap_area(unsigned long size, > unsigned long align, > unsigned long vstart, unsigned long vend, > int node, gfp_t gfp_mask, > - unsigned long va_flags) > + unsigned long va_flags, struct vm_struct *vm) > { > struct vmap_area *va; > unsigned long freed; > @@ -1627,9 +1627,12 @@ static struct vmap_area *alloc_vmap_area(unsigned long size, > > va->va_start = addr; > va->va_end = addr + size; > - va->vm = NULL; > + va->vm = vm; > va->flags = va_flags; > > + if (vm != NULL) > + vm->addr = (void *)addr; > + > spin_lock(&vmap_area_lock); > insert_vmap_area(va, &vmap_area_root, &vmap_area_list); > spin_unlock(&vmap_area_lock); > @@ -2039,7 +2042,8 @@ static void *new_vmap_block(unsigned int order, gfp_t gfp_mask) > va = alloc_vmap_area(VMAP_BLOCK_SIZE, VMAP_BLOCK_SIZE, > VMALLOC_START, VMALLOC_END, > node, gfp_mask, > - VMAP_RAM|VMAP_BLOCK); > + VMAP_RAM|VMAP_BLOCK, > + NULL); > if (IS_ERR(va)) { > kfree(vb); > return ERR_CAST(va); > @@ -2394,7 +2398,8 @@ void *vm_map_ram(struct page **pages, unsigned int count, int node) > struct vmap_area *va; > va = alloc_vmap_area(size, PAGE_SIZE, > VMALLOC_START, VMALLOC_END, > - node, GFP_KERNEL, VMAP_RAM); > + node, GFP_KERNEL, VMAP_RAM, > + NULL); > if (IS_ERR(va)) > return NULL; > > @@ -2548,14 +2553,6 @@ static inline void setup_vmalloc_vm_locked(struct vm_struct *vm, > va->vm = vm; > } > > -static void setup_vmalloc_vm(struct vm_struct *vm, struct vmap_area *va, > - unsigned long flags, const void *caller) > -{ > - spin_lock(&vmap_area_lock); > - setup_vmalloc_vm_locked(vm, va, flags, caller); > - spin_unlock(&vmap_area_lock); > -} > - > static void clear_vm_uninitialized_flag(struct vm_struct *vm) > { > /* > @@ -2592,14 +2589,16 @@ static struct vm_struct *__get_vm_area_node(unsigned long size, > if (!(flags & VM_NO_GUARD)) > size += PAGE_SIZE; > > - va = alloc_vmap_area(size, align, start, end, node, gfp_mask, 0); > + area->flags = flags; > + area->caller = caller; > + area->size = size; > + > + va = alloc_vmap_area(size, align, start, end, node, gfp_mask, 0, area); > if (IS_ERR(va)) { > kfree(area); > return NULL; > } > > - setup_vmalloc_vm(area, va, flags, caller); > - > /* > Thank you for improving this! That was in my radar quite a long time ago :) Some comments though. I think that such "partial" way of initializing of "vm_struct" or "vm" is not optimal because it becomes spread between two places. Also, i think that we should not remove the setup_vmalloc_vm() function, instead we can move it in a place where the VA is not inserted to the tree, i.e. to initialize before insert. The "locked" variant can be renamed to setup_vmalloc_vm(). Also, could you please post how you tested this patch and stress-ng figures? This is really good for other people and folk to know. Thanks! -- Uladzislau Rezki