From patchwork Fri Mar 1 15:54:16 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Huang, Rulin" X-Patchwork-Id: 13578641 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 34302C5475B for ; Fri, 1 Mar 2024 15:51:27 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9BF1E6B0081; Fri, 1 Mar 2024 10:51:26 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 9469E6B0082; Fri, 1 Mar 2024 10:51:26 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7C3506B0083; Fri, 1 Mar 2024 10:51:26 -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 6179B6B0081 for ; Fri, 1 Mar 2024 10:51:26 -0500 (EST) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id F3A05A11B0 for ; Fri, 1 Mar 2024 15:51:25 +0000 (UTC) X-FDA: 81848909730.14.569B496 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.17]) by imf08.hostedemail.com (Postfix) with ESMTP id E3B76160015 for ; Fri, 1 Mar 2024 15:51:23 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=KOuqAoTQ; spf=pass (imf08.hostedemail.com: domain of rulin.huang@intel.com designates 192.198.163.17 as permitted sender) smtp.mailfrom=rulin.huang@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1709308284; 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-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=d+IpvwFLLyvE7ikE4yEpOks4VSdczhpopVoaRh+unko=; b=159w0Es08tHdSOvlfPQMDJE2Ipo6ctHhuhbag4XindJPY5PzyEKFJFcVGJvtEGkUtkSRAS RXB1sS+qkyLyAOUDozVpF30Z1msi5zjtthP/thu38pnPaxLIs8E8wklJelzGpWxeLWqJZj idPjfmg9uIf3BsuwI1INrKwvAPeECQ8= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1709308284; a=rsa-sha256; cv=none; b=XGTWb5q+0d3h30dMkH1kX7AOWa+O9P21rmTBPywfH33xLPr/S/9EKLPt06c+jvGRtbJM9j OYXW6L04KDBRVNi0xcmcvvOryMEHoozx19/VRmP90oWe8QUUhkjBfgz66GpmsJOPPe4u0G Mk7/21FbPbMa82dPOY4dpCE02GZUl18= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=KOuqAoTQ; spf=pass (imf08.hostedemail.com: domain of rulin.huang@intel.com designates 192.198.163.17 as permitted sender) smtp.mailfrom=rulin.huang@intel.com; dmarc=pass (policy=none) header.from=intel.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1709308284; x=1740844284; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=PDWDDt4QR97SNsCyWpItSkT/i9E2ArftSSSpich7b2U=; b=KOuqAoTQwzClkMyPKnqDaP+lJr3tTquh7EKtzU6Z9J9LyVxRXc8DpjcR fr3xQrWOlolDx++naV5xhca0UXmMLL2+vuf1vWQNkBEC9XHe3KClh+WWa xT6IgfpwHxBj1Ca9aBBdvXLr0h9uu3nckgkjqU3aqiciD/+hEa8oqwiWU ZsaIEyvGlc0uJKhg3ow5TwcLduEugKtE15ZzyP8NPfB38HMzLUoskPjJV 7qqsrpOzDCvm6XxIAPWzH1PgzaJHrWYKcMaKsJvdcIyMZSZBSwj2ZF6+G rS/cKR84xjH8Oe0AUzTg5tAPhlPlbbx4LfHTsmBJ1SwJbZ04Ucgw4Hi3L w==; X-IronPort-AV: E=McAfee;i="6600,9927,11000"; a="3700842" X-IronPort-AV: E=Sophos;i="6.06,196,1705392000"; d="scan'208";a="3700842" Received: from fmviesa008.fm.intel.com ([10.60.135.148]) by fmvoesa111.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Mar 2024 07:51:23 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.06,196,1705392000"; d="scan'208";a="8370205" Received: from linux-pnp-server-09.sh.intel.com ([10.239.176.190]) by fmviesa008.fm.intel.com with ESMTP; 01 Mar 2024 07:51:20 -0800 From: rulinhuang To: urezki@gmail.com, bhe@redhat.com Cc: akpm@linux-foundation.org, colin.king@intel.com, hch@infradead.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, lstoakes@gmail.com, rulin.huang@intel.com, tianyou.li@intel.com, tim.c.chen@intel.com, wangyang.guo@intel.com, zhiguo.zhou@intel.com Subject: [PATCH v7 1/2] mm/vmalloc: Moved macros with no functional change happened Date: Fri, 1 Mar 2024 10:54:16 -0500 Message-ID: <20240301155417.1852290-2-rulin.huang@intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240301155417.1852290-1-rulin.huang@intel.com> References: <20240301155417.1852290-1-rulin.huang@intel.com> MIME-Version: 1.0 X-Rspamd-Queue-Id: E3B76160015 X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: ke3fg8858pz8ot9pkimt6opm13uobh9c X-HE-Tag: 1709308283-258402 X-HE-Meta: U2FsdGVkX19tWDYMKF1yL6m17oae0Y6DcUZcdqfiNaSIvhEX6ERlu1skZcdG1jID02RksgW2LG1Zc4AbFtF0iahmrvvE7glf/H+bfmKm6y1veIPMqQjJKTOShOmcCHVEIkRXEWD9GLc1qlnA2/blN8f8o+sYWR4E7jadEiU1wt0rmPv1gaFa0rqilSFZFlzDDrFDIgpPTSaJfIS5H6tMGGtx1nJlocN7DTs2T8/hs5XyIVZvCx/vIbAvFdvGr+NzHDvQMFMgQbnFxd25drKPzzUDNVxKDx61IOrOGYiETXfBQ3jHDyHidYBF7LfDqd0MxwlmGliW1zOyl9ASh54J9VyGh0itJR2Xs7pDOia37aV7Cs+PJ5XC6zX1lEXiIw0cs81MVZHH8Szh9iD1j6/nvdX3WyKg5wKM8AVkksTlq4i3KcH3wgTi5ALGtiFdM0tZPTb9av9Sfvrlcb4T1tNmN698aM77yljUGC/pQziBcSTXcdinDQbwaBj91ECa5I6vobd1kA/iOz9f0sSfC41m5ntkBJymeb3pMWlHVS6jZDI/aGBcsISzIw/FP+iALmhlYxh+3tprShpmcBE6gjD4QFbLJTPZy+5AtbGwCPxmi3AiU0U7XNSazASiK7MqLeZLK3GIVpUi/joigYVs2WxT0V2ZZ7IR31nL4HIpizAjgIOAeXgI3oaM5UhTY2Z7vn5IHpbi46VX9xiVa2da2i9TMXSsU/c9QsdOsQ3Nsz7KUTMgFYiLB2dWih8u9fU8g7zbMyClj6A+tD4pdpt1YHYA0i30RGBbwq6DNkrQf5aLVDaWtjcqXdqjaDJWY2VyXbADORk34EPHk0tUyGrIShHkMnkMkK9k++TNmQtcdiRxyRG1nVfUsJmgmyKwSF66ML7p 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: Moved data structures and basic helpers related to per cpu kva allocator up too to along with these macros with no functional change happened. Signed-off-by: rulinhuang Reviewed-by: Baoquan He Reviewed-by: Uladzislau Rezki (Sony) --- V6 -> V7: Adjusted the macros --- mm/vmalloc.c | 262 +++++++++++++++++++++++++-------------------------- 1 file changed, 131 insertions(+), 131 deletions(-) diff --git a/mm/vmalloc.c b/mm/vmalloc.c index 25a8df497255..fc027a61c12e 100644 --- a/mm/vmalloc.c +++ b/mm/vmalloc.c @@ -887,6 +887,137 @@ is_vn_id_valid(unsigned int node_id) return false; } +/* + * vmap space is limited especially on 32 bit architectures. Ensure there is + * room for at least 16 percpu vmap blocks per CPU. + */ +/* + * If we had a constant VMALLOC_START and VMALLOC_END, we'd like to be able + * to #define VMALLOC_SPACE (VMALLOC_END-VMALLOC_START). Guess + * instead (we just need a rough idea) + */ +#if BITS_PER_LONG == 32 +#define VMALLOC_SPACE (128UL*1024*1024) +#else +#define VMALLOC_SPACE (128UL*1024*1024*1024) +#endif + +#define VMALLOC_PAGES (VMALLOC_SPACE / PAGE_SIZE) +#define VMAP_MAX_ALLOC BITS_PER_LONG /* 256K with 4K pages */ +#define VMAP_BBMAP_BITS_MAX 1024 /* 4MB with 4K pages */ +#define VMAP_BBMAP_BITS_MIN (VMAP_MAX_ALLOC*2) +#define VMAP_MIN(x, y) ((x) < (y) ? (x) : (y)) /* can't use min() */ +#define VMAP_MAX(x, y) ((x) > (y) ? (x) : (y)) /* can't use max() */ +#define VMAP_BBMAP_BITS \ + VMAP_MIN(VMAP_BBMAP_BITS_MAX, \ + VMAP_MAX(VMAP_BBMAP_BITS_MIN, \ + VMALLOC_PAGES / roundup_pow_of_two(NR_CPUS) / 16)) + +#define VMAP_BLOCK_SIZE (VMAP_BBMAP_BITS * PAGE_SIZE) + +/* + * Purge threshold to prevent overeager purging of fragmented blocks for + * regular operations: Purge if vb->free is less than 1/4 of the capacity. + */ +#define VMAP_PURGE_THRESHOLD (VMAP_BBMAP_BITS / 4) + +#define VMAP_RAM 0x1 /* indicates vm_map_ram area*/ +#define VMAP_BLOCK 0x2 /* mark out the vmap_block sub-type*/ +#define VMAP_FLAGS_MASK 0x3 + +struct vmap_block_queue { + spinlock_t lock; + struct list_head free; + + /* + * An xarray requires an extra memory dynamically to + * be allocated. If it is an issue, we can use rb-tree + * instead. + */ + struct xarray vmap_blocks; +}; + +struct vmap_block { + spinlock_t lock; + struct vmap_area *va; + unsigned long free, dirty; + DECLARE_BITMAP(used_map, VMAP_BBMAP_BITS); + unsigned long dirty_min, dirty_max; /*< dirty range */ + struct list_head free_list; + struct rcu_head rcu_head; + struct list_head purge; +}; + +/* Queue of free and dirty vmap blocks, for allocation and flushing purposes */ +static DEFINE_PER_CPU(struct vmap_block_queue, vmap_block_queue); + +/* + * In order to fast access to any "vmap_block" associated with a + * specific address, we use a hash. + * + * A per-cpu vmap_block_queue is used in both ways, to serialize + * an access to free block chains among CPUs(alloc path) and it + * also acts as a vmap_block hash(alloc/free paths). It means we + * overload it, since we already have the per-cpu array which is + * used as a hash table. When used as a hash a 'cpu' passed to + * per_cpu() is not actually a CPU but rather a hash index. + * + * A hash function is addr_to_vb_xa() which hashes any address + * to a specific index(in a hash) it belongs to. This then uses a + * per_cpu() macro to access an array with generated index. + * + * An example: + * + * CPU_1 CPU_2 CPU_0 + * | | | + * V V V + * 0 10 20 30 40 50 60 + * |------|------|------|------|------|------|... + * CPU0 CPU1 CPU2 CPU0 CPU1 CPU2 + * + * - CPU_1 invokes vm_unmap_ram(6), 6 belongs to CPU0 zone, thus + * it access: CPU0/INDEX0 -> vmap_blocks -> xa_lock; + * + * - CPU_2 invokes vm_unmap_ram(11), 11 belongs to CPU1 zone, thus + * it access: CPU1/INDEX1 -> vmap_blocks -> xa_lock; + * + * - CPU_0 invokes vm_unmap_ram(20), 20 belongs to CPU2 zone, thus + * it access: CPU2/INDEX2 -> vmap_blocks -> xa_lock. + * + * This technique almost always avoids lock contention on insert/remove, + * however xarray spinlocks protect against any contention that remains. + */ +static struct xarray * +addr_to_vb_xa(unsigned long addr) +{ + int index = (addr / VMAP_BLOCK_SIZE) % num_possible_cpus(); + + return &per_cpu(vmap_block_queue, index).vmap_blocks; +} + +/* + * We should probably have a fallback mechanism to allocate virtual memory + * out of partially filled vmap blocks. However vmap block sizing should be + * fairly reasonable according to the vmalloc size, so it shouldn't be a + * big problem. + */ + +static unsigned long addr_to_vb_idx(unsigned long addr) +{ + addr -= VMALLOC_START & ~(VMAP_BLOCK_SIZE-1); + addr /= VMAP_BLOCK_SIZE; + return addr; +} + +static void *vmap_block_vaddr(unsigned long va_start, unsigned long pages_off) +{ + unsigned long addr; + + addr = va_start + (pages_off << PAGE_SHIFT); + BUG_ON(addr_to_vb_idx(addr) != addr_to_vb_idx(va_start)); + return (void *)addr; +} + static __always_inline unsigned long va_size(struct vmap_area *va) { @@ -2327,137 +2458,6 @@ static struct vmap_area *find_unlink_vmap_area(unsigned long addr) /*** Per cpu kva allocator ***/ -/* - * vmap space is limited especially on 32 bit architectures. Ensure there is - * room for at least 16 percpu vmap blocks per CPU. - */ -/* - * If we had a constant VMALLOC_START and VMALLOC_END, we'd like to be able - * to #define VMALLOC_SPACE (VMALLOC_END-VMALLOC_START). Guess - * instead (we just need a rough idea) - */ -#if BITS_PER_LONG == 32 -#define VMALLOC_SPACE (128UL*1024*1024) -#else -#define VMALLOC_SPACE (128UL*1024*1024*1024) -#endif - -#define VMALLOC_PAGES (VMALLOC_SPACE / PAGE_SIZE) -#define VMAP_MAX_ALLOC BITS_PER_LONG /* 256K with 4K pages */ -#define VMAP_BBMAP_BITS_MAX 1024 /* 4MB with 4K pages */ -#define VMAP_BBMAP_BITS_MIN (VMAP_MAX_ALLOC*2) -#define VMAP_MIN(x, y) ((x) < (y) ? (x) : (y)) /* can't use min() */ -#define VMAP_MAX(x, y) ((x) > (y) ? (x) : (y)) /* can't use max() */ -#define VMAP_BBMAP_BITS \ - VMAP_MIN(VMAP_BBMAP_BITS_MAX, \ - VMAP_MAX(VMAP_BBMAP_BITS_MIN, \ - VMALLOC_PAGES / roundup_pow_of_two(NR_CPUS) / 16)) - -#define VMAP_BLOCK_SIZE (VMAP_BBMAP_BITS * PAGE_SIZE) - -/* - * Purge threshold to prevent overeager purging of fragmented blocks for - * regular operations: Purge if vb->free is less than 1/4 of the capacity. - */ -#define VMAP_PURGE_THRESHOLD (VMAP_BBMAP_BITS / 4) - -#define VMAP_RAM 0x1 /* indicates vm_map_ram area*/ -#define VMAP_BLOCK 0x2 /* mark out the vmap_block sub-type*/ -#define VMAP_FLAGS_MASK 0x3 - -struct vmap_block_queue { - spinlock_t lock; - struct list_head free; - - /* - * An xarray requires an extra memory dynamically to - * be allocated. If it is an issue, we can use rb-tree - * instead. - */ - struct xarray vmap_blocks; -}; - -struct vmap_block { - spinlock_t lock; - struct vmap_area *va; - unsigned long free, dirty; - DECLARE_BITMAP(used_map, VMAP_BBMAP_BITS); - unsigned long dirty_min, dirty_max; /*< dirty range */ - struct list_head free_list; - struct rcu_head rcu_head; - struct list_head purge; -}; - -/* Queue of free and dirty vmap blocks, for allocation and flushing purposes */ -static DEFINE_PER_CPU(struct vmap_block_queue, vmap_block_queue); - -/* - * In order to fast access to any "vmap_block" associated with a - * specific address, we use a hash. - * - * A per-cpu vmap_block_queue is used in both ways, to serialize - * an access to free block chains among CPUs(alloc path) and it - * also acts as a vmap_block hash(alloc/free paths). It means we - * overload it, since we already have the per-cpu array which is - * used as a hash table. When used as a hash a 'cpu' passed to - * per_cpu() is not actually a CPU but rather a hash index. - * - * A hash function is addr_to_vb_xa() which hashes any address - * to a specific index(in a hash) it belongs to. This then uses a - * per_cpu() macro to access an array with generated index. - * - * An example: - * - * CPU_1 CPU_2 CPU_0 - * | | | - * V V V - * 0 10 20 30 40 50 60 - * |------|------|------|------|------|------|... - * CPU0 CPU1 CPU2 CPU0 CPU1 CPU2 - * - * - CPU_1 invokes vm_unmap_ram(6), 6 belongs to CPU0 zone, thus - * it access: CPU0/INDEX0 -> vmap_blocks -> xa_lock; - * - * - CPU_2 invokes vm_unmap_ram(11), 11 belongs to CPU1 zone, thus - * it access: CPU1/INDEX1 -> vmap_blocks -> xa_lock; - * - * - CPU_0 invokes vm_unmap_ram(20), 20 belongs to CPU2 zone, thus - * it access: CPU2/INDEX2 -> vmap_blocks -> xa_lock. - * - * This technique almost always avoids lock contention on insert/remove, - * however xarray spinlocks protect against any contention that remains. - */ -static struct xarray * -addr_to_vb_xa(unsigned long addr) -{ - int index = (addr / VMAP_BLOCK_SIZE) % num_possible_cpus(); - - return &per_cpu(vmap_block_queue, index).vmap_blocks; -} - -/* - * We should probably have a fallback mechanism to allocate virtual memory - * out of partially filled vmap blocks. However vmap block sizing should be - * fairly reasonable according to the vmalloc size, so it shouldn't be a - * big problem. - */ - -static unsigned long addr_to_vb_idx(unsigned long addr) -{ - addr -= VMALLOC_START & ~(VMAP_BLOCK_SIZE-1); - addr /= VMAP_BLOCK_SIZE; - return addr; -} - -static void *vmap_block_vaddr(unsigned long va_start, unsigned long pages_off) -{ - unsigned long addr; - - addr = va_start + (pages_off << PAGE_SHIFT); - BUG_ON(addr_to_vb_idx(addr) != addr_to_vb_idx(va_start)); - return (void *)addr; -} - /** * new_vmap_block - allocates new vmap_block and occupies 2^order pages in this * block. Of course pages number can't exceed VMAP_BBMAP_BITS