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 B602BC7619A for ; Mon, 27 Mar 2023 00:38:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B7FA36B0072; Sun, 26 Mar 2023 20:38:58 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B301B6B0074; Sun, 26 Mar 2023 20:38:58 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9F7936B0075; Sun, 26 Mar 2023 20:38:58 -0400 (EDT) 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 8F9796B0072 for ; Sun, 26 Mar 2023 20:38:58 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 30B0CA04E6 for ; Mon, 27 Mar 2023 00:38:58 +0000 (UTC) X-FDA: 80612818356.24.B02AE58 Received: from mail-pj1-f50.google.com (mail-pj1-f50.google.com [209.85.216.50]) by imf15.hostedemail.com (Postfix) with ESMTP id 440E4A0007 for ; Mon, 27 Mar 2023 00:38:55 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=fromorbit-com.20210112.gappssmtp.com header.s=20210112 header.b=Gfy6rgbq; dmarc=pass (policy=quarantine) header.from=fromorbit.com; spf=pass (imf15.hostedemail.com: domain of david@fromorbit.com designates 209.85.216.50 as permitted sender) smtp.mailfrom=david@fromorbit.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1679877536; 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=ZL3a+TWIB4wbyH+pk+yppXVzEy45w2PnT959afXZzfE=; b=XTmRqYvm6/VpAiDjJppIuiH2B7i6Lcg3tymxluhvIxKhfbEhtXX9cDn30rcR1pjG+t0dT4 QBE/nYTVItbUEVGGAH049YfGiJ7nTYvuRUQGG4oH875vn12POeU/3ll9eoRvSIAtExkl4U 8GEScpMekBCA5tmFqtITxODmg2bTW4Y= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=fromorbit-com.20210112.gappssmtp.com header.s=20210112 header.b=Gfy6rgbq; dmarc=pass (policy=quarantine) header.from=fromorbit.com; spf=pass (imf15.hostedemail.com: domain of david@fromorbit.com designates 209.85.216.50 as permitted sender) smtp.mailfrom=david@fromorbit.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1679877536; a=rsa-sha256; cv=none; b=vmjDgXCnpNKcIvIGymYcy8VnNZ4rxl4HuqftmktflfN+LCUQfxquUG+xLn1t9m3hxe106P l9vnu0A5iJ/EE92Lr0269/fKC77vUq4lOZNDSMyYxol8eqpuDtyVNREhlz7lq8t052/knw btCtBWkVoMqaa/LvXlndrfVChTjw8ns= Received: by mail-pj1-f50.google.com with SMTP id lr16-20020a17090b4b9000b0023f187954acso6957562pjb.2 for ; Sun, 26 Mar 2023 17:38:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fromorbit-com.20210112.gappssmtp.com; s=20210112; t=1679877535; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=ZL3a+TWIB4wbyH+pk+yppXVzEy45w2PnT959afXZzfE=; b=Gfy6rgbqQVzlNT/IqFJC4s7YUkiSfRHkSozUxvidIMjOLmOwomJ5cqMjYLGOoAJ2uW BSr2RUY/EQtVtt2Rgzv6fJM3bXde2QyLTjhZ3GDyu6tPvjmJirsmt3NOcQ4sdjWGL7HM w5J4XUDP9RplRMJ/7PO+1/a/Ou/XwCwAEYemRsZgoaybiN7WY7MYd6m7bTa/AUoaH4ff 7PY7hNTaHUA1u5ATl+6dTxBG3FYljAZ6LnSCrm7xkRL6EOwDjFCwDxBrirqvH03aqWWz nyyMbDRtciGtEzzRC9W1IAGWhGZ9idnqglS5SONBeH03aOGgo8/1Gw8AIqEYf79cIDy4 zUjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679877535; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=ZL3a+TWIB4wbyH+pk+yppXVzEy45w2PnT959afXZzfE=; b=LzqJ3nCEyZy7NIz27HHZmQFmUudXsxy5jXcqgxoxJQvvDBJTTupfGJStVggsSzm1nZ elk/EqpRWNpZ8OJp0F08zU7jovbibcF0xEloe4o7pM9cIlKOF6c81o8EAyxfHzGiAIAh m3MGfBh+7dO0EvNeg8ypz2lsfzTgC5oM11sV8cJFbyE0SJRkVhMIaLwxR98rRRWMeGQk WGr+v6KGTa1ElB8onV8ZB8RqQtPvWxHteRmHM8KOSHGWnGrxnzNqKpaFmCHQIUuB5VK2 gaiyDmGsqyEhq54qEmfpWBtKJh5wocqQjEZI9iypMfzPlEmaZwxAbhW9o4RlfTg9k1tN VrkQ== X-Gm-Message-State: AAQBX9dyj6GEJV5l1YArVkjhuWBcpTIy9rWXo9OlU+8n+W9v56/oyMHB ItghpLLMrmgJT3TkpwG6yxYkCA== X-Google-Smtp-Source: AKy350Zn6mhhHR8MBqsUL/fpMKj0au7tP24g1nhgaaInJCemK83mogbizHRNfMnFFf6N1TmLLZFOAA== X-Received: by 2002:a17:90b:17c9:b0:237:9cc7:28a6 with SMTP id me9-20020a17090b17c900b002379cc728a6mr10658956pjb.26.1679877534805; Sun, 26 Mar 2023 17:38:54 -0700 (PDT) Received: from dread.disaster.area (pa49-181-91-157.pa.nsw.optusnet.com.au. [49.181.91.157]) by smtp.gmail.com with ESMTPSA id dw18-20020a17090b095200b002407750c3c3sm1432675pjb.37.2023.03.26.17.38.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 26 Mar 2023 17:38:53 -0700 (PDT) Received: from dave by dread.disaster.area with local (Exim 4.92.3) (envelope-from ) id 1pgasr-00Da2e-QH; Mon, 27 Mar 2023 11:38:49 +1100 Date: Mon, 27 Mar 2023 11:38:49 +1100 From: Dave Chinner To: Matthew Wilcox Cc: Uladzislau Rezki , 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: <20230327003849.GA3222767@dread.disaster.area> 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-Server: rspam02 X-Rspamd-Queue-Id: 440E4A0007 X-Stat-Signature: 9omiskku16bbo6mgu4q84t9axpynrtgo X-HE-Tag: 1679877535-650868 X-HE-Meta: U2FsdGVkX19VThbDQ55p3tttXngzi13sVyHoaKLwWcLsPX0yn2EKjfitC5FZIt2fPlh4RsOHPQxr97uXvqO0RWNb+1keEmICEJfh8aIxAzW6ThPEuSNT8EkrDLji6gCVT5cAV0W0rWstKIKlWdDq1ixFy94gNpqg/PJf26FcVlcmKTXDMaIa23DA1huHyS2u4rzSOviKhZSkdF9/ymn/4e7z7jCC3TgkkBZyDrtLIoyNd2kV+P83S5r5GXoULazPNs+U0QNgYpdpwuLUmfbUcbDHBE9y4cPImhYV82Z/KgGMhdahj1/WWza/6H1eS1WU3n3LsPczK4NLzX7/kPzrpVARW87FCrwBj6EkdlDviKCa27mOmJF2egC9v6Rs46NhUWpw/514cY+nObIqBP61wgvnuGmgJJperWlAaWYlyFIPPQXRl1XMsSPKeRR1XPUEN2yxjVPyd0Khikl5GJsy+YX1vSWd0J+HrSiVxY2Yc//lbAMS6+hrLWGTvWUEXv2Xjx8nT1QAaKSqRi+690rUqbmipNyTXd6Q2FYpvthcexGpZr7XhMZLrij0a57JEo3aXcGBnLy84QHmtKkpSqkRODt5Wj1x0E5vXy1RAXYvJDHGPuKKn1WY2OrCUaCEULEKeOb4lGciisnqGTfWvUZBoXDJzy1WLCtkN4igaAvMX/obgMSyvJle6E9Ogfh32LXxxbVP4nSgmiMIx26e9sJnJ6p6VfA4jbyPlwfwnvGhFIONJlGRcq+DYo8ENjvZ+2vcBZPhPNiUEpZkk2l8g2hdkG1cVNWiajStvKE9O7MXJf6JBEVx1OjWD/wwClH+eVFQSwbShgtV+Fku957RxQ6PcrVwmmAW6bhCjkSUg+4AQftUhN9HT9PEZ1y4ZHzv3cIFTeaHlj9EUYpOvgUGoO3qkXTWP3WC7ASHJ4/5H5tEQwZR5dzt8rWMO/H47+rJhhWoBBtVzubROdLoPuSpB7J HQhRdyb6 a2dOkG/bUZIAuqD+u0nuT5fwWHfCg/lCSa6kn9sKXu7PQMETpUFxVeywwnZAqy2G7eJoH3B+9x+AdpzIvwJQPsU6tyQxrFAX4UX9FJDAo+GKImdAjKCs3cJQ2N0OPY0YD8ou39T3BHFIKEhFavb/YjuQheFxWvVmvgElQEfv0WwrfjGtZBEpuVSgp0yHF55abuQYvfIzDDN4F3rygDcIuKDTQI91cCU+XiGs64v3FmP9N0ncIN2GExT0HIDSgTV2uACDpoO6y8l8P1O0MnaSegVHZemntt5Ux82RlNh7l3kRlLld9UvYRozESAJi1mbILcxjMwWUXJeUPvljy20cQkryqMEvasxaRYBPjkSe/j7kCN40YbrJvi1Z+8RJxuQePKqVWa/iN/1YWmGhHU45R7YfaRVWWV4o3KJv4puTvWoXkIlUEgcf2fB0x9fVIUcm+UeJdWNc76/vts/bwX/J/rDApJZg488V9CK/SUFf+VDWjcaLvvgxqFYm/P48HngNyCsJijfHTRlR++kTvRyy1123YG5ZZlNPvdNu7UrDTelQPSJ6iC6e86q+gjgD9ffJ9xac4 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 Fri, Mar 24, 2023 at 05:31:55AM +0000, Matthew Wilcox wrote: > On Fri, Mar 24, 2023 at 04:25:39PM +1100, Dave Chinner wrote: > > Did you read the comment above this function? I mean, it's all about > > how poorly kvmalloc() works for the highly concurrent, fail-fast > > context that occurs in the journal commit fast path, and how we open > > code it with kmalloc and vmalloc to work "ok" in this path. > > > > Then if you go look at the commits related to it, you might find > > that XFS developers tend to write properly useful changelogs to > > document things like "it's better, but vmalloc will soon have lock > > contention problems if we hit it any harder".... > > The problem with writing whinges like this is that mm developers don't > read XFS changelogs. I certainly had no idea this was a problem, and > I doubt anybody else who could make a start at fixing this problem had > any idea either. Why go to all this effort instead of sending an email > to linux-mm? If you read the mm/vmalloc.c change logs, you'd find that two weeks later, a bunch of commits went into the vmalloc code to change some of the stuff mentioned in the above XFS commit. That was a direct result of the discussion of vmalloc/kvmalloc inadequacies, and if you followed the links from these three commits: 30d3f01191d3 mm/vmalloc: be more explicit about supported gfp flags. 9376130c390a mm/vmalloc: add support for __GFP_NOFAIL 451769ebb7e7 mm/vmalloc: alloc GFP_NO{FS,IO} for vmalloc You'd have found those discussions. I went into great detail in that discussion about the problems with the kvmalloc/vmalloc APIs and the problems with actually using it in anger. e.g: https://lore.kernel.org/all/163184741778.29351.16920832234899124642.stgit@noble.brown/T/#e8bc85de35d432dcbc35a16fc72b6a3daef2a0f78 In that discussion, I gave these examples and use cases about fail-fast for the kmalloc part of kvmalloc being needed, that arguments that GFP_NOFS didn't work with vmalloc were bullshit because we'd been using it heavily for years in GFP_NOFS contexts without issues, the lack of scope APIs for anything other NOFS/NOIO, that filesytsems want "retry forever" semantics, not the current __GFP_NOFAIL semantics that have all sorts of weird side effects, etc. I also point out that vmalloc is rapidly becoming one of the hottest paths in XFS in response to the comments that vmalloc "isn't a hot path". Indeed, I point that the XFS change in that commit during that discussion, and you made exactly the same "you should raise this with mm developers" complaint then, too. Imagine how frsutrating it is when I was being told to raise vmalloc issues on the linux-mm list with mm developers during a discussion about vmalloc issues with mm developers on the linux-mm list. Especially as it wasn't just one mm developer that responded like that. And yet, the 3 commits that came out of the discussion did nothing to change the actual problem we need to fix - fail-fast high-order kmalloc behaviour in kvmalloc() - and so the XFS commit still stands and is badly needed. Repeatedly castigating people saying we should talk to mm developers rather than working around the API they maintain when we've repeatedly talked to the mm developers about getting changes made and repeatedly failed to get the changes we need made? Yeah, that leads to frustrations and commit messages documenting all the shit we haven't been able to get changed and so need to work around..... -Dave. -- Dave Chinner david@fromorbit.com