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 89267C6FD1F for ; Wed, 22 Mar 2023 13:18:27 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E0A196B0071; Wed, 22 Mar 2023 09:18:26 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DBA106B0072; Wed, 22 Mar 2023 09:18:26 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C81CC6B007B; Wed, 22 Mar 2023 09:18:26 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id B9C326B0071 for ; Wed, 22 Mar 2023 09:18:26 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 74B971603C4 for ; Wed, 22 Mar 2023 13:18:26 +0000 (UTC) X-FDA: 80596588212.16.546CFB8 Received: from mail-lj1-f178.google.com (mail-lj1-f178.google.com [209.85.208.178]) by imf10.hostedemail.com (Postfix) with ESMTP id 813A3C0027 for ; Wed, 22 Mar 2023 13:18:24 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=cBYo1FbI; spf=pass (imf10.hostedemail.com: domain of urezki@gmail.com designates 209.85.208.178 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=1679491104; a=rsa-sha256; cv=none; b=5xGh3EViBFrBJ0f7ZLLyGBppFirqGckhF+x9AUueIQv3xEiQmRtu4VGK6Hwaq2CjwAK/nS hgT8QZdjPvOSff0KLPEXOs4+/g1fwhOJTBpkjhZZJn4mv+SXKjKnR60cnf5+xpXzl9lT6L HtDX/H2y95HhMA8Z2wctJfwnlKWd0IQ= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=cBYo1FbI; spf=pass (imf10.hostedemail.com: domain of urezki@gmail.com designates 209.85.208.178 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=1679491104; 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=flvUuqT7GguHLAZYu3Nm/bRmU352FoDCbqfDGEpJXGs=; b=Ep2Z6gDi3vBFu1TRSj/nsJHNZ2HWV8l3nG8nJ5CR8Am0O8EUMJezqT7Zubb+RLt/DXb3Vk 82mCz7E9Q5uwhR38vT2jlNTRz1pK4BfVfiGeAPi3U5Mr3wz5ME/NU4C1bFP9O34r0FeWDf piPa3VXB0eIKsV6naIb+lfrKmf4BffI= Received: by mail-lj1-f178.google.com with SMTP id e21so6323801ljn.7 for ; Wed, 22 Mar 2023 06:18:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1679491102; 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=flvUuqT7GguHLAZYu3Nm/bRmU352FoDCbqfDGEpJXGs=; b=cBYo1FbI7Jag2GTpMY+3zGMEfp45hgTlC6Wy8rucio3I5YvnyKBnBE6H3GbnDMg9bI G5y/UcjXalkfDSQ7S/VJOWIkg5vejUTJZtYMAxK6hRJ7Tm0xIT8YPn82BKgiLrafALxV p9z5qzN9P0cZFx2AQiOLa7GydS0kWotuv/9+bhFlF0z7gZwBb3qm2ARB2izXlu59lUES H/5Sbarbhda4Qi/J2LdyGU7uNG5TfV4EEOfbaxjCwv/2GL+OfL1szUnosY6EBNVXLYEt nxuD94i9BYsoX9ZcLQ5kImlgmSzkvDrGgTQ+FgQmRLUoiTjNgXotONBi56kwRHC8OnE+ 2rLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679491102; 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=flvUuqT7GguHLAZYu3Nm/bRmU352FoDCbqfDGEpJXGs=; b=UEAAsTQ8l/rVgkE9ijRn3FJ9sej7enJHVvxsznAr6lakhStBWxvbKzh9tTMMjiewiX kmqnrUtnI2tSCofH3udePgaglbd9tF+zcRNEqI40z2XZQ7flqFSHEje1KiWHe1BEbpZN m08npkh1lZ5fu6VVhp7ant+df2gkM6K/TyRELeCkhanGCo1+mAv4l8YGageNYMDbofq1 H4YpnukeVPGufCzKqboDfPHiFxsTn4meVa9pjrd3KDq/JleVsXDdQfm5K9PM33tf5Euv 9kE2KaSIRERPA1LPLPn0fMhl4ucxY+CIf/sSOJItk+T9Au68PQtfBa0P7ArK1omNX/5p BJhg== X-Gm-Message-State: AO0yUKWY49YLXCZTMNlq/AM6jinuj+6w0EqczhTcuIwABUgWd5O/KYKk T8+RJWvZrAuO5UGYWh4gh74= X-Google-Smtp-Source: AK7set9RwGqwYhj9ISqc56aQk5wwiN4IHmCG8ijpaEJoHXQH05SRdgCq9r4OaAFTXDVw7yolslvkuA== X-Received: by 2002:a2e:7309:0:b0:29b:d471:c817 with SMTP id o9-20020a2e7309000000b0029bd471c817mr2157580ljc.12.1679491102542; Wed, 22 Mar 2023 06:18:22 -0700 (PDT) Received: from pc636 (host-90-233-209-15.mobileonline.telia.com. [90.233.209.15]) by smtp.gmail.com with ESMTPSA id y2-20020a05651c020200b00295a33eda65sm2601091ljn.137.2023.03.22.06.18.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 22 Mar 2023 06:18:22 -0700 (PDT) From: Uladzislau Rezki X-Google-Original-From: Uladzislau Rezki Date: Wed, 22 Mar 2023 14:18:19 +0100 To: Dave Chinner Cc: Lorenzo Stoakes , linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, Andrew Morton , Baoquan He , Uladzislau Rezki , Matthew Wilcox , 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-Rspam-User: X-Rspamd-Queue-Id: 813A3C0027 X-Rspamd-Server: rspam01 X-Stat-Signature: gukyubf3tsbz4en6kforoowzz44ho1w9 X-HE-Tag: 1679491104-838479 X-HE-Meta: U2FsdGVkX1+2WOrkByX01Pv1TPfHq3GqE2Jec2AUVoOpqbRkGwgycOJ/F+8yUmMTUVrMslDCAvjxYPMwNOzSG/rU2mvL0lJWMGsbOXfwJSDve6FmpqvIXfPpMxvCjQO3wgRvMQLgtkuZbzd+5YO3GwBMZ5KSypReknQEi23XOe8bRHvXe++Wp8ToPY1/H6YH5evtIJpE7FibMfuhXNqq+69ar7FRgGGOWIc0XPFoYEwR+BfqSJaxZivTW+wZg6c1dTLhTEFRA6akC8wbkYMjYJsMv+L6QXLSSRwoffhPsr2vtTyh1ysGPKHabaM3EOT6PI6QI8JU1KBJFEAJeG9TOPEaqSDJXaS5q59orzgJrF5mgIBwjGhWipG0/C8M+V63fTsj5X72ax6lkt7wCyBqnAaGXFmf3Mu6qbUJNuQ0DW75GPNxJjml8yMQoUsmasqvWujPV3m/4HdMacxdLC5zTFk5bWX5cP1SJDjIrL/x8yVAR3Tk1xWhraH+lTf7o5G2B1Rbo4+dPzqsuhQYltgA1OPVCwTEptdCHJfVLqqxDCXAhUIfG/15mX3m2QE+/JQeoxjAH3Y3nTJbKyMI+VQRTC1yszM+T2KMnV+wAGJJtTZePgaDx8LhKyAwrsmIK/pMoZzgVl2CjV2GWuff2Ox39xYXdLcUNN+VHTMbRbAfY/nuOpP1EURIcSrSLOyJv60m18pf5w0D3+zQvz1J6p4WqtWQNmUwn32iTUXovkZp0H3HJtSaZW6sumn0NETXaDrVAnvRmN0XpyZx3I7DT2gC94fOAzMs9Kaqc1TA91ZqaRUBnClz2dRcuvUX16hXezyWogm5nrO4ato0au472G38vQgqz9yClU1MH8s9f+x/OfCG6024M2O/7BTQbXNhAPszxEMLtcEW4Ud5K/U9LGlLUOVqVg3OTeBpjIVg7oo1ykjn9CTAvlKtxHpzllBcNMwVq5IC0YbQaH2uX9t9INR 0n1LqHiz o/AO/S6m8A+CWR0E+Eygk8oTeyx3UHMO0iEzTAS/qYkwcMvZOYHCY/BV5QfAY9kcJySB9e3ipEFbjuKY9/kZo3G5XQsZrt3BTJsGRDfZFREXT5af1/rfXNjkkptk6I4GXoWDX0r868k5b6ib09QiKKRIvxrmvowoPUNck78dGpV5rqND7k0R0NEWmKvYOcAHWI9jCGXbjJkP+y6jHRsuNKPNYawfDq95kLDKxNszZT1xCSQzZxhw8p+EuFfivtv3wtXyjySijRy7tiPHWs9eHZptSVlAnvv4ClkbANBs9m7v/vvnI4WBHE1M1l87n/OBG4c7DOnZLc2dldFwPSZ259co7vhThlin+FHt4lSMBVxv4+Z6hQqw3Xldd7FjdA+JBCFwXSP3vQD4eXonVyMVUqkShYOdKLfGuTg8jVmS4kxvQfcX1kvAeJfEITWRRJvJvd9SQgEeV4+PaLYcil91IPjq+BT34vs4XwqaV8MFb7T4hK3vxsQTEMIfAzw== 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: 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 ./ ./xfs_log_priv.h:675: * Log vector and shadow buffers can be large, so we need to use kvmalloc() here ./xfs_log_priv.h:676: * to ensure success. Unfortunately, kvmalloc() only allows GFP_KERNEL contexts ./xfs_log_priv.h:677: * to fall back to vmalloc, so we can't actually do anything useful with gfp ./xfs_log_priv.h:678: * flags to control the kmalloc() behaviour within kvmalloc(). Hence kmalloc() ./xfs_log_priv.h:681: * vmalloc if it can't get somethign straight away from the free lists or ./xfs_log_priv.h:682: * buddy allocator. Hence we have to open code kvmalloc outselves here. ./xfs_log_priv.h:686: * allocations. This is actually the only way to make vmalloc() do GFP_NOFS ./xfs_log_priv.h:691:xlog_kvmalloc( ./xfs_log_priv.h:702: p = vmalloc(buf_size); ./xfs_bio_io.c:21: unsigned int is_vmalloc = is_vmalloc_addr(data); ./xfs_bio_io.c:26: if (is_vmalloc && op == REQ_OP_WRITE) ./xfs_bio_io.c:56: if (is_vmalloc && op == REQ_OP_READ) ./xfs_log.c:1976: if (is_vmalloc_addr(iclog->ic_data)) ./xfs_log_cil.c:338: lv = xlog_kvmalloc(buf_size); ./libxfs/xfs_attr_leaf.c:522: args->value = kvmalloc(valuelen, GFP_KERNEL | __GFP_NOLOCKDEP); ./kmem.h:12:#include ./kmem.h:78: if (is_vmalloc_addr(addr)) ./kmem.h:79: return vmalloc_to_page(addr); ./xfs_attr_item.c:84: * This could be over 64kB in length, so we have to use kvmalloc() for ./xfs_attr_item.c:85: * this. But kvmalloc() utterly sucks, so we use our own version. ./xfs_attr_item.c:87: nv = xlog_kvmalloc(sizeof(struct xfs_attri_log_nameval) + ./scrub/attr.c:60: ab = kvmalloc(sizeof(*ab) + sz, flags); urezki@pc638:~/data/raid0/coding/linux-rcu.git/fs/xfs$ Thanks! -- Uladzislau Rezki