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 EC68DC4332F for ; Thu, 8 Dec 2022 19:52:58 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 26BBE8E000C; Thu, 8 Dec 2022 14:52:58 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 21C238E0001; Thu, 8 Dec 2022 14:52:58 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0E48D8E000C; Thu, 8 Dec 2022 14:52:58 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id F39D98E0001 for ; Thu, 8 Dec 2022 14:52:57 -0500 (EST) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 207F8120E95 for ; Thu, 8 Dec 2022 19:52:57 +0000 (UTC) X-FDA: 80220187194.30.9DFCB67 Received: from mail-ej1-f44.google.com (mail-ej1-f44.google.com [209.85.218.44]) by imf03.hostedemail.com (Postfix) with ESMTP id 5863A20007 for ; Thu, 8 Dec 2022 19:52:54 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=fyYeafmB; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf03.hostedemail.com: domain of urezki@gmail.com designates 209.85.218.44 as permitted sender) smtp.mailfrom=urezki@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1670529174; 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=Cbt5AP/opVLc7mMBSSuU1JbLyeELh40EDgvhnoHJP70=; b=hDoc1jYAbtCkYTuBLU6H3NjWvo+WUwdG+Ao9jbIfjfenT6urjz2vAkDKtAcqAv0AEyowqU QEGbjXeqVBsupjT+3ns0Fk7XRz+OPzQg6jlmkLG9VDu1Ij7ieP8O2iQZR6fWWZfQ5zK/fM tWwcCnjjr9DKgy+pB1/bCsxyFqiq4FE= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=fyYeafmB; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf03.hostedemail.com: domain of urezki@gmail.com designates 209.85.218.44 as permitted sender) smtp.mailfrom=urezki@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1670529174; a=rsa-sha256; cv=none; b=w740Zz1Anwji5tF2iIEdH8mjf2ti4DzGhOP8ScwpVc7B6K7tHSF/3i8cYiAS7nTlD3KRV3 pagJg+1vtkUCFml0oxpVD7R46/hNLiRCkBS09VVC6YdvDTwaZqEj29px9/2oD9Z4ksJQev 37cOLkuapbRNsS4o3DflXFSDz8gByIs= Received: by mail-ej1-f44.google.com with SMTP id b2so6506335eja.7 for ; Thu, 08 Dec 2022 11:52:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; 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=Cbt5AP/opVLc7mMBSSuU1JbLyeELh40EDgvhnoHJP70=; b=fyYeafmB6c2C0PZNOSzG2fMQws/DAdxSprCidbNS2n7zzH+51oGt5mYtwqlYLChtjL qVVXu91amMPeax6kKa92akWxT5LhsFZGvSX4Xz1PO8P+IDUvvDFABVjLIPeUNtwtFNzh F+MZcmx/zC4R5K4KpKUrI2RaY+NWyjbHDmL17PlzTCc6fK1OPn01iv2arCi+T0mQoRaF fqerH8kKZbr/8IXsfEx33JPsNzXs+LPbMKMNa+D7tKeXys58dqdX0w8dlky17dPeLbk0 iEFS4eS9sEYxp/yPVhFA7X0GiYIakCXNNrXdAFqA5QOZe4cNJ+7GoWTEXBJoak0BRn8B xB0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=Cbt5AP/opVLc7mMBSSuU1JbLyeELh40EDgvhnoHJP70=; b=MKHicOeVRDHVKYCKOD1KnBKXo3zyDHtnQtNWuPni5LRDmmrTes36W8a8PYLXTkzgGx jET8TqEAhcyEA2khI3me4qxCqKD6lfUs90NuOrumh8jZeZZxallB7C2jLRLqpgw/I0m5 A2mBWEY8PrC1+JX0vJPVT4oCKDHY6nhZdSCYzlS2mxdsbNBU3EB0ie1JrfFPCjHgYeUA 4SfbyNt4DZ8APmz7b3CBrXq9cn8+EQRuX2kGUi2j0wxvFIqFWBA1fblCrn0hQZLSyvc2 TGU/K3Nyn94EqHb2k1Tg0aV52fAt2NhGLZtN5X5mUzu6mVOLA1J+xHAWIP2Rfv3JgN1g tq/Q== X-Gm-Message-State: ANoB5pkgcO7Dr+sAnQcnardXhSpJ0YW0GQtRXkINalcPOcvsS6EbvXh/ nvXJPJJn3zTnYEum0WFTFQU= X-Google-Smtp-Source: AA0mqf5ptS1ysFEt5E9ddx06NKu6/xOtdByMq9Zr7XTuRascFI3VgS0SzOtgCo3B5td0KRXiqPfQCg== X-Received: by 2002:a17:906:37d5:b0:7c0:a961:8aad with SMTP id o21-20020a17090637d500b007c0a9618aadmr3213884ejc.34.1670529172683; Thu, 08 Dec 2022 11:52:52 -0800 (PST) Received: from pc636 ([155.137.26.201]) by smtp.gmail.com with ESMTPSA id o17-20020a170906769100b00782fbb7f5f7sm10009703ejm.113.2022.12.08.11.52.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 08 Dec 2022 11:52:52 -0800 (PST) From: Uladzislau Rezki X-Google-Original-From: Uladzislau Rezki Date: Thu, 8 Dec 2022 20:52:50 +0100 To: Baoquan He Cc: Uladzislau Rezki , linux-kernel@vger.kernel.org, linux-mm@kvack.org, stephen.s.brennan@oracle.com, willy@infradead.org, akpm@linux-foundation.org, hch@infradead.org Subject: Re: [PATCH v1 2/7] mm/vmalloc.c: add flags to mark vm_map_ram area Message-ID: References: <20221204013046.154960-1-bhe@redhat.com> <20221204013046.154960-3-bhe@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 5863A20007 X-Rspamd-Server: rspam09 X-Rspam-User: X-Stat-Signature: 8q6kcrohhngwatr71hducxnzqs1ym6zy X-HE-Tag: 1670529174-554144 X-HE-Meta: U2FsdGVkX19rkuBBAAIn6W2NA21OkVAewgxtkvtY9q4kXaQFJMHGr0aTZh0ScXgIJuWwqRUR7pg2nvGnROStAIgaLFADwmM2UfNbhw/JV2l3o+w4CWSzxdRrPfbB3gXjAGr86ptEL2237dHKwF8B/wWTDh3e4KM0ea9Wp5RVcBQRz4uH5B/VyOf2P9+8Wjm6nf3fdNIB1Hez3CJ/zWq+jVCWBlWIpZUPXmkHEBl0C9+nGD5GI/fJnhKnxJCaJTusqHEeX/zHrD2QWDs0+n7BcJCRwvaj2UDV/vrwPr25JqzC6l0w5RdMAtnxa55YzacP6OcYVuPDYBJol6nVwwkwA1He3XCbJE/OvAuPpBK+Sa/qrMZ+x0dNSPUbuAvtLWs6wp9HEepknBHiQiBvJy4vUw+v2eUJ1mLrJbqRVPY6Nl9j2u4aDSnMAhtaueKNP02+a1knmto/ruyOPc7RV/kOjD/V6lXfP/v1BY0qsOd1TzNe14RUT0RyzlSjw26ailXkHU3bvzwCxhAHFfe13Y1x3G/GPHjmVyrMLTesZTfLdShl+OFexdGHcKCxM1ZkSAp4U0k9Jza8xUCXmwcgfOsSNuksP13F8BaNdZYTEkwyWJfm7LD8vL26COQfxNnxPXhYLx2O8CmgHTxXKu3KxjBdAMsuQXcu+PYcLFxuZ1AqQi6yI8225qnrxZhuArL+kyjXVBsX/fiZq+NkI0nSg0MxtDMtO2s1J/IDv2WQGzy9smNSN7JhUNGkyh5JhXA1QlGb/0samtdeCDHh28a+cbdr67HCb+zugSdW8Xs9GAnuKKsDzeYIZsusO7dAMXHZCbgvs0csXa0bExAGqc9gqBtao74uLefkcam/zeExf2kLL4x1igNSK5lgqld4Y4M/5+pKAWRbZ8TGpk31QYRaUgFRtPsn04Q6eNIIfoZ09HQDgnEAAzt1AIkvpeF2xsWn6qu8XnPsvYA/ZKPfVeUJBKX mh3HS3GX bBZuG2cb3HYbzV/jzxiN/6VewBxhBFPlnGb373UzSF4eNKiblGmTFrM4iTBTKZ4ru6wO5LEwrHyqCfLpYqtO4aupHkK9A3scvJm2Fo4pO/0Ixtyo9NjeeKPNlMUe6KWCbZvSgDGVEO8rzDXQ= 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: On Wed, Dec 07, 2022 at 04:03:41PM +0800, Baoquan He wrote: > On 12/05/22 at 01:56pm, Uladzislau Rezki wrote: > > > Through vmalloc API, a virtual kernel area is reserved for physical > > > address mapping. And vmap_area is used to track them, while vm_struct > > > is allocated to associate with the vmap_area to store more information > > > and passed out. > > > > > > However, area reserved via vm_map_ram() is an exception. It doesn't have > > > vm_struct to associate with vmap_area. And we can't recognize the > > > vmap_area with '->vm == NULL' as a vm_map_ram() area because the normal > > > freeing path will set va->vm = NULL before unmapping, please see > > > function remove_vm_area(). > > > > > > Meanwhile, there are two types of vm_map_ram area. One is the whole > > > vmap_area being reserved and mapped at one time; the other is the > > > whole vmap_area with VMAP_BLOCK_SIZE size being reserved, while mapped > > > into split regions with smaller size several times via vb_alloc(). > > > > > > To mark the area reserved through vm_map_ram(), add flags field into > > > struct vmap_area. Bit 0 indicates whether it's a vm_map_ram area, > > > while bit 1 indicates whether it's a vmap_block type of vm_map_ram > > > area. > > > > > > This is a preparatoin for later use. > > > > > > Signed-off-by: Baoquan He > > > --- > > > include/linux/vmalloc.h | 1 + > > > mm/vmalloc.c | 18 +++++++++++++++++- > > > 2 files changed, 18 insertions(+), 1 deletion(-) > > > > > > diff --git a/include/linux/vmalloc.h b/include/linux/vmalloc.h > > > index 096d48aa3437..69250efa03d1 100644 > > > --- a/include/linux/vmalloc.h > > > +++ b/include/linux/vmalloc.h > > > @@ -76,6 +76,7 @@ struct vmap_area { > > > unsigned long subtree_max_size; /* in "free" tree */ > > > struct vm_struct *vm; /* in "busy" tree */ > > > }; > > > + unsigned long flags; /* mark type of vm_map_ram area */ > > > }; > > > > > > /* archs that select HAVE_ARCH_HUGE_VMAP should override one or more of these */ > > > diff --git a/mm/vmalloc.c b/mm/vmalloc.c > > > index 5d3fd3e6fe09..d6f376060d83 100644 > > > --- a/mm/vmalloc.c > > > +++ b/mm/vmalloc.c > > > @@ -1815,6 +1815,7 @@ static void free_vmap_area_noflush(struct vmap_area *va) > > > > > > spin_lock(&vmap_area_lock); > > > unlink_va(va, &vmap_area_root); > > > + va->flags = 0; > > > spin_unlock(&vmap_area_lock); > > > > > This is not a good place to set flags to zero. It looks to me like > > corner and kind of specific. > > Thanks for reviewing. > > Here, I thought to clear VMAP_RAM|VMAP_BLOCK on vmap->flags when free > the vmap_block. I didn't find a good place to do the clearing. When we > call free_vmap_block(), we either come from purge_fragmented_blocks(), > or from vb_free(). In vb_free(), it will call free_vmap_block() when > the whole vmap_block is dirty. In purge_fragmented_blocks(), it will > try to purge all vmap_block which only has dirty or free regions. > For both of above functions, they will call free_vmap_block() when > there's no being used region in the vmap_block. > > purge_fragmented_blocks() > vb_free() > -->free_vmap_block() > > So seems we don't need to clear the VMAP_RAM|VMAP_BLOCK on vmap->flags > because there's no mapping existed in the vmap_block. The consequent > free_vmap_block() will remove the relevant vmap_area from vmap_area_list > and vmap_area_root tree. > > So I plan to remove code change in this place. > > > > > > > nr_lazy = atomic_long_add_return((va->va_end - va->va_start) >> > > > @@ -1887,6 +1888,10 @@ struct vmap_area *find_vmap_area(unsigned long addr) > > > > > > #define VMAP_BLOCK_SIZE (VMAP_BBMAP_BITS * PAGE_SIZE) > > > > > > +#define VMAP_RAM 0x1 > > > +#define VMAP_BLOCK 0x2 > > > +#define VMAP_FLAGS_MASK 0x3 > > > + > > > struct vmap_block_queue { > > > spinlock_t lock; > > > struct list_head free; > > > @@ -1967,6 +1972,9 @@ static void *new_vmap_block(unsigned int order, gfp_t gfp_mask) > > > kfree(vb); > > > return ERR_CAST(va); > > > } > > > + spin_lock(&vmap_area_lock); > > > + va->flags = VMAP_RAM|VMAP_BLOCK; > > > + spin_unlock(&vmap_area_lock); > > > > > The per-cpu code was created as a fast per-cpu allocator because of high > > vmalloc lock contention. If possible we should avoid of locking of the > > vmap_area_lock. Because it has a high contention. > > Fair enough. I made below draft patch to address the concern. By > adding argument va_flags to alloc_vmap_area(), we can pass the > vm_map_ram flags into alloc_vmap_area and filled into vmap_area->flags. > With this, we don't need add extra action to acquire vmap_area_root lock > and do the flags setting. Is it OK to you? > > From 115f6080b339d0cf9dd20c5f6c0d3121f6b22274 Mon Sep 17 00:00:00 2001 > From: Baoquan He > Date: Wed, 7 Dec 2022 11:08:14 +0800 > Subject: [PATCH] mm/vmalloc: change alloc_vmap_area() to pass in va_flags > > With this change, we can pass and set vmap_area->flags for vm_map_ram area > in alloc_vmap_area(). Then no extra action need be added to acquire > vmap_area_lock when doing the vmap_area->flags setting. > > Signed-off-by: Baoquan He > --- > mm/vmalloc.c | 13 +++++++++---- > 1 file changed, 9 insertions(+), 4 deletions(-) > > diff --git a/mm/vmalloc.c b/mm/vmalloc.c > index ccaa461998f3..d74eddec352f 100644 > --- a/mm/vmalloc.c > +++ b/mm/vmalloc.c > @@ -1586,7 +1586,9 @@ preload_this_cpu_lock(spinlock_t *lock, gfp_t gfp_mask, int node) > 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) > + int node, gfp_t gfp_mask, > + unsigned long va_flags) > +) > { > struct vmap_area *va; > unsigned long freed; > @@ -1630,6 +1632,7 @@ static struct vmap_area *alloc_vmap_area(unsigned long size, > va->va_start = addr; > va->va_end = addr + size; > va->vm = NULL; > + va->flags = va_flags; > > spin_lock(&vmap_area_lock); > insert_vmap_area(va, &vmap_area_root, &vmap_area_list); > @@ -1961,7 +1964,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); > + node, gfp_mask, > + VMAP_RAM|VMAP_BLOCK); > if (IS_ERR(va)) { > kfree(vb); > return ERR_CAST(va); > @@ -2258,7 +2262,8 @@ void *vm_map_ram(struct page **pages, unsigned int count, int node) > } else { > struct vmap_area *va; > va = alloc_vmap_area(size, PAGE_SIZE, > - VMALLOC_START, VMALLOC_END, node, GFP_KERNEL); > + VMALLOC_START, VMALLOC_END, > + node, GFP_KERNEL, VMAP_RAM|VMAP_BLOCK); > if (IS_ERR(va)) > return NULL; > > @@ -2498,7 +2503,7 @@ 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); > + va = alloc_vmap_area(size, align, start, end, node, gfp_mask, 0); > if (IS_ERR(va)) { > kfree(area); > return NULL; > -- > 2.34.1 > Yes, this is better than it was before. Adding an extra parameter makes it more valid and logical. -- Uladzislau Rezki