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 29092C352A1 for ; Wed, 7 Dec 2022 08:03:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6E1798E0003; Wed, 7 Dec 2022 03:03:52 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 691F18E0001; Wed, 7 Dec 2022 03:03:52 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5595A8E0003; Wed, 7 Dec 2022 03:03:52 -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 422ED8E0001 for ; Wed, 7 Dec 2022 03:03:52 -0500 (EST) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 0DA07A0869 for ; Wed, 7 Dec 2022 08:03:52 +0000 (UTC) X-FDA: 80214771504.19.3205246 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf09.hostedemail.com (Postfix) with ESMTP id 0A944140002 for ; Wed, 7 Dec 2022 08:03:50 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=gVVQweOA; spf=pass (imf09.hostedemail.com: domain of bhe@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=bhe@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1670400231; 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=/ZK2czWg/DEIeFiIGwHXFZG1Ys/EXQYtJrnesdlM28Y=; b=kDfV0uRgXyHBeGhSVCu3RM7L4fljRX5VlUw1XxI/G2JmkeUPu7hJWGJBo+QldLqaBlxj+C nRUBiBJ3tXzQyQd42kFJMyVKncwfNMK1SOpsMFARdcRmfeXPcRWH1lZPPvX1jIK5YGXJ1X X3FSpugnpJN+kryG20wWnxdItZm37BU= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=gVVQweOA; spf=pass (imf09.hostedemail.com: domain of bhe@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=bhe@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1670400231; a=rsa-sha256; cv=none; b=KF3Faqa69xYF4Cl0pEdOHji7aqrvhd0uFYza3cPiWfTm4twAG8nt4MiGhcnjwCJvEBJ87F 5JnDG2/whAwYkYLv5dWXCiItvjs4gmf7T0oF/McdjlqUffk7y0X6uy6S7fAjrLxiZ75+rv 0fdvauMxM2JABHnLZTcRUWk/uzK79SQ= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1670400230; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=/ZK2czWg/DEIeFiIGwHXFZG1Ys/EXQYtJrnesdlM28Y=; b=gVVQweOAnV9sMFITubArtdby0fTd4Q7yl3nuCqRRylbj6th2bGDk6VNt8IGelh2s/XwTgr X5IF7PXonbjZ3c9uYuYfeXNMQ8a5z3zBaYzaHMgEhrrkHdrYpNA5SMgSpuiWfDd+G+HLOb H3iuhLAhbtNcJEcC8ghUWVGlqCmJPTs= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-624-qvwxPhpAOYWkqHyt-y4m4Q-1; Wed, 07 Dec 2022 03:03:47 -0500 X-MC-Unique: qvwxPhpAOYWkqHyt-y4m4Q-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 9D49B3813F2D; Wed, 7 Dec 2022 08:03:46 +0000 (UTC) Received: from localhost (ovpn-13-181.pek2.redhat.com [10.72.13.181]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 6EF55C15BB5; Wed, 7 Dec 2022 08:03:45 +0000 (UTC) Date: Wed, 7 Dec 2022 16:03:41 +0800 From: Baoquan He To: Uladzislau Rezki Cc: 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-Scanned-By: MIMEDefang 3.1 on 10.11.54.8 X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 0A944140002 X-Stat-Signature: mgu5s6hpw7xacyu9jup7nyqiu9e1n93r X-Spamd-Result: default: False [-5.40 / 9.00]; BAYES_HAM(-6.00)[100.00%]; SUBJECT_HAS_UNDERSCORES(1.00)[]; DMARC_POLICY_ALLOW(-0.50)[redhat.com,none]; MID_RHS_NOT_FQDN(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:170.10.133.0/24]; R_DKIM_ALLOW(-0.20)[redhat.com:s=mimecast20190719]; RCVD_NO_TLS_LAST(0.10)[]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_SEVEN(0.00)[7]; FROM_EQ_ENVFROM(0.00)[]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[redhat.com:+]; TO_DN_SOME(0.00)[]; ARC_SIGNED(0.00)[hostedemail.com:s=arc-20220608:i=1]; TC_DOMAIN_MIX_CASE(0.00)[] X-Rspam-User: X-HE-Tag: 1670400230-950936 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 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