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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id A79A8C74A5B for ; Mon, 27 Mar 2023 00:39:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231771AbjC0AjJ (ORCPT ); Sun, 26 Mar 2023 20:39:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56284 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230354AbjC0AjF (ORCPT ); Sun, 26 Mar 2023 20:39:05 -0400 Received: from mail-pj1-x1036.google.com (mail-pj1-x1036.google.com [IPv6:2607:f8b0:4864:20::1036]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 69391469E for ; Sun, 26 Mar 2023 17:38:55 -0700 (PDT) Received: by mail-pj1-x1036.google.com with SMTP id qe8-20020a17090b4f8800b0023f07253a2cso6939711pjb.3 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=MmMIHnLR2ENBacOdHXnV/yTj1IQu07Sc7SWi22txS9IoaIhztQeMQpkTwtXlV6hOgP caneptDn4J2iI4pFlXngVJIJQY3rwRdt69FyJKd9XUy/sIX/bKZPYWlHsNImjUa3zaOR KC4wto40Z4iT41we2QuVDqmbPqqCDjEbkGNJFZm+y4LeT8yIyRkZ0Vi8dN+v9bmb3r8n 3qgi5eJ3TV+DVb+fUaEkitX2a688YbFLGgdePjGS0H/tbHDshbxn5++pz+7j6HAvwhUi uJfjfna7RfP2MRyxgeSi+yDQpyl6QWoatle9eKkUaQOkyENW6ZuzKldHOQHp1SvFiRFJ dVTA== X-Gm-Message-State: AAQBX9d3gQ+DiDjvJCJO9yzYk6zKR2uE0hIUORHvQGREVcSUtvZ9CTUe wBdFJygdD71RNqIru6FXACmfkw== 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: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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