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 508DBC6FD1F for ; Wed, 22 Mar 2023 19:15:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D791F6B0071; Wed, 22 Mar 2023 15:15:16 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D298F6B0072; Wed, 22 Mar 2023 15:15:16 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BC94A6B0075; Wed, 22 Mar 2023 15:15:16 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id AD59D6B0071 for ; Wed, 22 Mar 2023 15:15:16 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 659DA1C5E01 for ; Wed, 22 Mar 2023 19:15:16 +0000 (UTC) X-FDA: 80597487432.29.EE9BBFA Received: from mail-lf1-f52.google.com (mail-lf1-f52.google.com [209.85.167.52]) by imf08.hostedemail.com (Postfix) with ESMTP id 67FF9160011 for ; Wed, 22 Mar 2023 19:15:14 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=QQKl+EQI; spf=pass (imf08.hostedemail.com: domain of urezki@gmail.com designates 209.85.167.52 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=1679512514; 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=cCBOvdCKd4EqIlOnayTxMvjd+KY/f+rwaK56Y7Wx9rI=; b=YsUFTBURQczLs+xknvLlsUiSB/NPQcMGxW1SQgYPwaR3Knhvn8Zh+16zr186/Rdy61xTMb 4xeaiQcJclY8AcwiwvCtSad25zYjDxIrZeEwFmuo9LyDuTnx2beyJLnJHqrYF9Kw9IxKwi nYi0KfGRqPgnphvUEzWDG0UH01kuS8M= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=QQKl+EQI; spf=pass (imf08.hostedemail.com: domain of urezki@gmail.com designates 209.85.167.52 as permitted sender) smtp.mailfrom=urezki@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1679512514; a=rsa-sha256; cv=none; b=MlidrxrGGCtNIgXusxL6qXThZVt+Bufi8SnejVQnlIwlAr6C9dvrC5o4e+rfdxVuX5jUI9 gapcsNyB9hL1G3VMh7IJO3PsjsjRWgQvLKW1KVV6yZXcjUlzg1ZCy+Ll1tFI6XXJB10zp2 CXn9uF5GF/USSxA/BYu0vAz7TmtB3D4= Received: by mail-lf1-f52.google.com with SMTP id s8so24489494lfr.8 for ; Wed, 22 Mar 2023 12:15:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1679512512; 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=cCBOvdCKd4EqIlOnayTxMvjd+KY/f+rwaK56Y7Wx9rI=; b=QQKl+EQIuLgIWW+CDj2/TlrdtUO0L68jIHNmhN+F2aZQknmUnrA92+rQwESJ57H6jn 36KMM4RGtls5WBSsB5a9ym1Wc4YSZdb1MR4vVCHb7zhKQjuYkLv5GA3/2vQj1qpSYMvS ZRxN31yMd3rO/qynuyE7jSPddERYpoUv2K9InOXlSzXKu8qogb6+p0YLHe7y7/Gc21vo R4y9gxCfnn1I6ugbRpTJOMDEjlyukmNVKdn4peDKTjwZ5yvsgkC/8yVqFh9h9OxaYqEv qZSrFZtns2tArlohtOHGlh/geR59d6vTojKXf1LHmWV1VWcptGNxqzyONGdiGt2NYmJ/ bTxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679512512; 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=cCBOvdCKd4EqIlOnayTxMvjd+KY/f+rwaK56Y7Wx9rI=; b=O2NWwMP3ozTfGpbPVqzwGKNAQCL96bZtiJ6bPMoWieTtppgMg7FQefxZ7fxRzBS5Bm T7S9m+7Y/jhBYdOMQ1oxC8qWn3+irnIInYtc5uMoFkNvWvh0d7IIo+Yo2IEqEIraCbnH uUn/xnCYcpzPGEuF1Td45IKW4jSkaXQHXD8UkjHyDKqfu814vXm8boK+eAXbh/twSxhQ a+3GairycIExlWhZ2cNmDsYlgqWO7ngPeMwJ/z11+9D2nF72BpoTCTdyoXU/Kld2RwHv NB2O7oqxzMnE8o7wLqzHfQlsp5K/C7+MTRuy5fnx6YzJM19nZ1mZLVuE9t6H/6Bh6sqq xGCw== X-Gm-Message-State: AO0yUKVhpqr6q8iUed+KceXdJbtgUkjcQZkNzcriFi2b5RzKQ6q170z9 mRL8UcU3+nzneSOEQ84mo2U= X-Google-Smtp-Source: AK7set8QC1xqmQlCK6G97WU8ztT4PvHsdLL5/PtfWwcwvb3Mwf29QeUzPsYgrBWEl2542LYgyzX2Jg== X-Received: by 2002:ac2:44d9:0:b0:4dd:ad88:ba5c with SMTP id d25-20020ac244d9000000b004ddad88ba5cmr2335638lfm.4.1679512512076; Wed, 22 Mar 2023 12:15:12 -0700 (PDT) Received: from pc636 (host-90-233-209-15.mobileonline.telia.com. [90.233.209.15]) by smtp.gmail.com with ESMTPSA id o7-20020a05651238a700b004b4b600c093sm2652682lft.92.2023.03.22.12.15.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 22 Mar 2023 12:15:11 -0700 (PDT) From: Uladzislau Rezki X-Google-Original-From: Uladzislau Rezki Date: Wed, 22 Mar 2023 20:15:09 +0100 To: Matthew Wilcox , Dave Chinner Cc: Matthew Wilcox , Dave Chinner , Lorenzo Stoakes , linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, Andrew Morton , Baoquan He , David Hildenbrand , Liu Shixin , Jiri Olsa Subject: Re: [PATCH v2 2/4] mm: vmalloc: use rwsem, mutex for vmap_area_lock and vmap_block->lock Message-ID: References: <6c7f1ac0aeb55faaa46a09108d3999e4595870d9.1679209395.git.lstoakes@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Stat-Signature: zipsr9k85c8y5epxqeby6txt7ieefdoz X-Rspam-User: X-Rspamd-Queue-Id: 67FF9160011 X-Rspamd-Server: rspam06 X-HE-Tag: 1679512514-977338 X-HE-Meta: U2FsdGVkX1/BrI+HNNihy3EAZLJFPk+XLtNhloR5q+45Aw64VibidvYNvQFP/b4CNl45Maxg2Hn5VeojvHMSIaO7WGGS6lTVCGD4Fabp9p7SBvCfCoaukeAKYj0gDB2K8i6LnDLKtoba4dDjVXxdx6jS1iPz0tZJJGv0xlkcXep7cPB/SIA64/eNaqnj5/WTXvcc8mOAqkIIXO7d7sCjvYlQN+Lg+uwM0Itqg5KpC9sXq3mV8EenAPS518igXkGbHGd5+EOcaPB7UztJcURbPiyHn6UcIv+YIg7sd+OSd6jnxarbOdY7S4+NYLgGqK11ISHex7NLo8rN80oUIf/nuZ2qFzmGwJy2h1UGukMy2ExXCCUctnexKkzk+1qxLImDU+0T1++RiuRakWI55wCdIDVjHJmhnnpeN8i/jum5aE7y6Zf8laxs1BOCjAbRM/NG+2P8Ciyz0kV9kKWHJ44hI8I3h2+9k9psOf/alCgAxqgHech4tRTafrYw5OIEbfGmWAaU4E1wnprP0BTwoAkT716mJ/LJd6a1pMz+dd8IBlxRmOkz4qcGGqIemxMG/lJR8Q7SrCpn497XqAdUI+hxvR6eQji6HHmXjZ6qzMP12dTx/meFWrskDPS2r13wL7EeDbJfDkHoQ3ePhAeDhqGIo7OUwQny1QPw3uMxSPmY2vhNOxd4N5G9BKHv2rRhIacUyM0yq8ltTJ+b3dYU+aZZ4+tSD4nZDcx1K5exrSxd6B+/rT70B9sDxT1o3eyu9Oz0mQ3fawtysWUr0lfL2M2gPQ8DJ50ouGIP9oHO5lA+FHlgP2+oIUmw3fVOmVNJaEK9R5QQBLPL2Qs/Na3Xu/Kqox/NtsUNWmAKtqr1EasuFktTseWnjf0f9YRXTZe2RZuWnsjseirkaQiJNp9Fh1TK3ATYEKyiIDnpkbXdhkHWoeSK0UoAJzBG9Qlxkr+j7i5g9WaTqK4R8rg7nbKRZoE T5xHcAIu wNXxEJht4zRzrfx7YCiJ7K9BsfJTFNqaRb0uRsaaPsRiEZsEJ204Cg7KD8DVm3oNkuHI7uiUQQCmPg+SdDjGVTmm7W6BKHkww2ltZdXdZ1UdLNsrBa8hndQNl/UAhssjNUYBNovA5faMP9vJeAMWa5tSyQiFQWJR6mhbxRCtkUqGscvyQOl5voJZbnRF+6el4u1qPu15RnNfr115HUq0JOQL289cbJuE/mqW4PH+/3Z96CoMbQNXM74JBRJeCJzjbsZ+2sSe+OHS90QFBKNm+tNLo6n8lz9IokFp6ftMUK67GMnL4EFHSDCN6XRG+9RkXOKOC9YKfGIfj9Ev+ohWaqLU9q4PNTbbmj4QQBIU28wxE2vDYns7R2U+PYxfGz4PMpQHgCWygPnLz6g5q+2LsgKNEx7kbvIxa8pFXSVirqT1Dm+tzsI9RMX8L3Wa6cP/ynIlrdZSneLkcwxQkQ990qeq5xFZjj7UiF/tJr9jf9Uj2HTuc1Ivu9Ytekoim5/T8J5Rh3GWe/OpGkNRwereltblI0g== 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, Mar 22, 2023 at 07:01:59PM +0100, Uladzislau Rezki wrote: > On Wed, Mar 22, 2023 at 05:47:28PM +0000, Matthew Wilcox wrote: > > On Wed, Mar 22, 2023 at 02:18:19PM +0100, Uladzislau Rezki wrote: > > > Hello, Dave. > > > > > > > > > > > I'm travelling right now, but give me a few days and I'll test this > > > > against the XFS workloads that hammer the global vmalloc spin lock > > > > really, really badly. XFS can use vm_map_ram and vmalloc really > > > > heavily for metadata buffers and hit the global spin lock from every > > > > CPU in the system at the same time (i.e. highly concurrent > > > > workloads). vmalloc is also heavily used in the hottest path > > > > throught the journal where we process and calculate delta changes to > > > > several million items every second, again spread across every CPU in > > > > the system at the same time. > > > > > > > > We really need the global spinlock to go away completely, but in the > > > > mean time a shared read lock should help a little bit.... > > > > > > > Could you please share some steps how to run your workloads in order to > > > touch vmalloc() code. I would like to have a look at it in more detail > > > just for understanding the workloads. > > > > > > Meanwhile my grep agains xfs shows: > > > > > > > > > urezki@pc638:~/data/raid0/coding/linux-rcu.git/fs/xfs$ grep -rn vmalloc ./ > > > > You're missing: > > > > fs/xfs/xfs_buf.c: bp->b_addr = vm_map_ram(bp->b_pages, bp->b_page_count, > > > > which i suspect is the majority of Dave's workload. That will almost > > certainly take the vb_alloc() path. > > > Then it has nothing to do with vmalloc contention(i mean global KVA allocator), IMHO. > Unless: > > > void *vm_map_ram(struct page **pages, unsigned int count, int node) > { > unsigned long size = (unsigned long)count << PAGE_SHIFT; > unsigned long addr; > void *mem; > > if (likely(count <= VMAP_MAX_ALLOC)) { > mem = vb_alloc(size, GFP_KERNEL); > if (IS_ERR(mem)) > return NULL; > addr = (unsigned long)mem; > } else { > struct vmap_area *va; > va = alloc_vmap_area(size, PAGE_SIZE, > VMALLOC_START, VMALLOC_END, node, GFP_KERNEL); > if (IS_ERR(va)) > return NULL; > > > number of pages > VMAP_MAX_ALLOC. > > That is why i have asked about workloads because i would like to understand > where a "problem" is. A vm_map_ram() access the global vmap space but it happens > when a new vmap block is required and i also think it is not a problem. > > But who knows, therefore it makes sense to have a lock at workload. > There is a lock-stat statistics for vm_map_ram()/vm_unmap_ram() test. I did it on 64 CPUs system with running 64 threads doing mapping/unmapping of 1 page. Each thread does 10 000 000 mapping + unmapping in a loop: root@pc638:/home/urezki# cat /proc/lock_stat lock_stat version 0.4 ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- class name con-bounces contentions waittime-min waittime-max waittime-total waittime-avg acq-bounces acquisitions holdtime-min holdtime-max holdtime-total holdtime-avg ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- vmap_area_lock: 2554079 2554276 0.06 213.61 11719647.67 4.59 2986513 3005712 0.05 67.02 3573323.37 1.19 -------------- vmap_area_lock 1297948 [<00000000dd41cbaa>] alloc_vmap_area+0x1c7/0x910 vmap_area_lock 1256330 [<000000009d927bf3>] free_vmap_block+0x4a/0xe0 vmap_area_lock 1 [<00000000c95c05a7>] find_vm_area+0x16/0x70 -------------- vmap_area_lock 1738590 [<00000000dd41cbaa>] alloc_vmap_area+0x1c7/0x910 vmap_area_lock 815688 [<000000009d927bf3>] free_vmap_block+0x4a/0xe0 vmap_area_lock 1 [<00000000c1d619d7>] __get_vm_area_node+0xd2/0x170 ..................................................................................................................................................................................................... vmap_blocks.xa_lock: 862689 862698 0.05 77.74 849325.39 0.98 3005156 3005709 0.12 31.11 1920242.82 0.64 ------------------- vmap_blocks.xa_lock 378418 [<00000000625a5626>] vm_map_ram+0x359/0x4a0 vmap_blocks.xa_lock 484280 [<00000000caa2ef03>] xa_erase+0xe/0x30 ------------------- vmap_blocks.xa_lock 576226 [<00000000caa2ef03>] xa_erase+0xe/0x30 vmap_blocks.xa_lock 286472 [<00000000625a5626>] vm_map_ram+0x359/0x4a0 .................................................................................................................................................................................................... free_vmap_area_lock: 394960 394961 0.05 124.78 448241.23 1.13 1514508 1515077 0.12 30.48 1179167.01 0.78 ------------------- free_vmap_area_lock 385970 [<00000000955bd641>] alloc_vmap_area+0xe5/0x910 free_vmap_area_lock 4692 [<00000000230abf7e>] __purge_vmap_area_lazy+0x10a/0x7d0 free_vmap_area_lock 4299 [<00000000eed9ff9e>] alloc_vmap_area+0x497/0x910 ------------------- free_vmap_area_lock 371734 [<00000000955bd641>] alloc_vmap_area+0xe5/0x910 free_vmap_area_lock 17007 [<00000000230abf7e>] __purge_vmap_area_lazy+0x10a/0x7d0 free_vmap_area_lock 6220 [<00000000eed9ff9e>] alloc_vmap_area+0x497/0x910 ..................................................................................................................................................................................................... purge_vmap_area_lock: 169307 169312 0.05 31.08 81655.21 0.48 1514794 1515078 0.05 67.73 912391.12 0.60 -------------------- purge_vmap_area_lock 166409 [<0000000050938075>] free_vmap_area_noflush+0x65/0x370 purge_vmap_area_lock 2903 [<00000000fb8b57f7>] __purge_vmap_area_lazy+0x47/0x7d0 -------------------- purge_vmap_area_lock 167511 [<0000000050938075>] free_vmap_area_noflush+0x65/0x370 purge_vmap_area_lock 1801 [<00000000fb8b57f7>] __purge_vmap_area_lazy+0x47/0x7d0 alloc_vmap_area is a top and second one is xa_lock. But the test i have done is pretty high concurrent scenario. -- Uladzislau Rezki