All of lore.kernel.org
 help / color / mirror / Atom feed
From: Uladzislau Rezki <urezki@gmail.com>
To: Baoquan He <bhe@redhat.com>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	stephen.s.brennan@oracle.com, urezki@gmail.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
Date: Mon, 5 Dec 2022 13:56:29 +0100	[thread overview]
Message-ID: <Y43qfdseyq0zizJO@pc636> (raw)
In-Reply-To: <20221204013046.154960-3-bhe@redhat.com>

> 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 <bhe@redhat.com>
> ---
>  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.


>  	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.

>  
>  	vaddr = vmap_block_vaddr(va->va_start, 0);
>  	spin_lock_init(&vb->lock);
> @@ -2229,8 +2237,12 @@ void vm_unmap_ram(const void *mem, unsigned int count)
>  		return;
>  	}
>  
> -	va = find_vmap_area(addr);
> +	spin_lock(&vmap_area_lock);
> +	va = __find_vmap_area((unsigned long)addr, &vmap_area_root);
>  	BUG_ON(!va);
> +	if (va)
> +		va->flags &= ~VMAP_RAM;
> +	spin_unlock(&vmap_area_lock);
>  	debug_check_no_locks_freed((void *)va->va_start,
>  				    (va->va_end - va->va_start));
>  	free_unmap_vmap_area(va);
> @@ -2269,6 +2281,10 @@ void *vm_map_ram(struct page **pages, unsigned int count, int node)
>  		if (IS_ERR(va))
>  			return NULL;
>  
> +		spin_lock(&vmap_area_lock);
> +		va->flags = VMAP_RAM;
> +		spin_unlock(&vmap_area_lock);
> +
>
Same here.

--
Uladzislau Rezki


  reply	other threads:[~2022-12-05 12:56 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-04  1:30 [PATCH v1 0/7] mm/vmalloc.c: allow vread() to read out vm_map_ram areas Baoquan He
2022-12-04  1:30 ` [PATCH v1 1/7] mm/vmalloc.c: add used_map into vmap_block to track space of vmap_block Baoquan He
2022-12-04  1:30 ` [PATCH v1 2/7] mm/vmalloc.c: add flags to mark vm_map_ram area Baoquan He
2022-12-05 12:56   ` Uladzislau Rezki [this message]
2022-12-07  8:03     ` Baoquan He
2022-12-08 19:52       ` Uladzislau Rezki
2022-12-09  8:27         ` Baoquan He
2022-12-04  1:30 ` [PATCH v1 3/7] mm/vmalloc.c: allow vread() to read out vm_map_ram areas Baoquan He
2022-12-04  3:47   ` kernel test robot
2022-12-17  1:14     ` Baoquan He
2022-12-04  1:30 ` [PATCH v1 4/7] mm/vmalloc: explicitly identify vm_map_ram area when shown in /proc/vmcoreinfo Baoquan He
2022-12-04  1:30 ` [PATCH v1 5/7] mm/vmalloc: skip the uninitilized vmalloc areas Baoquan He
2022-12-04  1:30 ` [PATCH v1 6/7] powerpc: mm: add VM_IOREMAP flag to the vmalloc area Baoquan He
2022-12-04  1:30   ` Baoquan He
2022-12-04  1:30 ` [PATCH v1 7/7] sh: mm: set " Baoquan He

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Y43qfdseyq0zizJO@pc636 \
    --to=urezki@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=bhe@redhat.com \
    --cc=hch@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=stephen.s.brennan@oracle.com \
    --cc=willy@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.