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 60318CE79AD for ; Wed, 20 Sep 2023 05:44:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9738B6B0105; Wed, 20 Sep 2023 01:44:58 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 923136B0106; Wed, 20 Sep 2023 01:44:58 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 843266B0107; Wed, 20 Sep 2023 01:44:58 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 731C86B0105 for ; Wed, 20 Sep 2023 01:44:58 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 439D7160F0C for ; Wed, 20 Sep 2023 05:44:58 +0000 (UTC) X-FDA: 81255887076.12.DA6711C Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by imf26.hostedemail.com (Postfix) with ESMTP id 5E4EE140016 for ; Wed, 20 Sep 2023 05:44:56 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=linux.microsoft.com header.s=default header.b=dtToQtEu; spf=pass (imf26.hostedemail.com: domain of ssengar@linux.microsoft.com designates 13.77.154.182 as permitted sender) smtp.mailfrom=ssengar@linux.microsoft.com; dmarc=pass (policy=none) header.from=linux.microsoft.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1695188696; a=rsa-sha256; cv=none; b=7rBcl1n3OEbp0znMOswGoEb77hEaxJ0KKN33HS096ORcGnGa2imnZIEZ+Ly62Y620/jAEP r3HQpdV3hC2MxaWyDOQc0+7DuZ6jZj3y9F+3Qckfh9Gp0rSmgWfbEerFzORQdEfFU+v+1c H2w927wVISzP8GVhs4MVJcnDqZ6t+tE= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=linux.microsoft.com header.s=default header.b=dtToQtEu; spf=pass (imf26.hostedemail.com: domain of ssengar@linux.microsoft.com designates 13.77.154.182 as permitted sender) smtp.mailfrom=ssengar@linux.microsoft.com; dmarc=pass (policy=none) header.from=linux.microsoft.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1695188696; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=8sN6z5YjhtFz0yFNj635BK3PS4McjJIaFDZfvIlqfVc=; b=OxU+U49mOH6Ukq3xEn9oGf7j1zknUfdnqfUoeCbJw1QZaUpVmKtOXRIliQPtf9zd4mVrcE sykc7MgI+LZC6LqlUJpKTpIhzG5+l9ZvcnE9pELE7j3Orl2IoI/yiUB8FCKWrmlI9En4EV F7XUypQTbWqjqupUeKF2eZNSzn5xIk8= Received: by linux.microsoft.com (Postfix, from userid 1127) id F0D91212C4AD; Tue, 19 Sep 2023 22:44:54 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com F0D91212C4AD DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1695188694; bh=8sN6z5YjhtFz0yFNj635BK3PS4McjJIaFDZfvIlqfVc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=dtToQtEuwQZb7hcE7TLvwY/My32GHeJ1ZpuVKZd56M5ZFH7HgSj9Czng7E7u2XMKa Q9yLQXt/7xIxy+wWEWcJ/cd9xLSWgYNy2SgNx2EpX4llBySS6khuFt3+W7zTu/rAr6 6biQCqzz5XgLwyr0gj7cskhmgjPq4QBVEhoZ61qY= Date: Tue, 19 Sep 2023 22:44:54 -0700 From: Saurabh Singh Sengar To: Zach O'Keefe Cc: David Hildenbrand , Matthew Wilcox , Saurabh Singh Sengar , "linux-mm@kvack.org" , Yang Shi , "linux-kernel@vger.kernel.org" , Greg KH Subject: Re: [EXTERNAL] Re: [PATCH v3] mm/thp: fix "mm: thp: kill __transhuge_page_enabled()" Message-ID: <20230920054454.GA26860@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> References: <37c2b525-5c2c-d400-552c-9ccb91f4d7bf@redhat.com> <3e08d48b-7b70-cc7f-0ec1-12ad9b1a33db@redhat.com> <3408ff54-f353-0334-0d66-c808389d2f01@redhat.com> <9f967665-2cbd-f80b-404e-ac741eab1ced@redhat.com> <20230906065817.GA27879@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20230906065817.GA27879@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 5E4EE140016 X-Stat-Signature: jmbh9cxi6pf9famtgszhtquozj1chxdx X-Rspam-User: X-HE-Tag: 1695188696-1284 X-HE-Meta: U2FsdGVkX1/+mrBgpMvdoY6aW8yIp5sFXeq9CajxbXH+Cq3MuCONeSHJ+fEqWVND1aT4bCrWba5V99+jnM+f6oO5kjYJG+Qf3JP/vn/nFjouHxoBnLXpkjvTawNzdoN6o/OVJ5o3TunxxosY6hYCVdhTqVlAlE8HwNYZs61PwrxWlVApX9dy32ulc47x74GjPZ1TM2r/gDx4N2dIJrNFcN9DsqUaHVtDOej+PEFOb7VJNA8YD7sJnMpWR2S1eFuTMaccyg8D2gvaBHdurneA3+03GHqNdk6GfkHwMTrosO1gX+Uy26nX2C0qFB7EjMBEMYKjxPeE8tcrRV5vxF7Uct5uWlb3vOO460F8NgjrVVGwF2U3sBIshvDE5SwpXo5SF+xCXR4AIuIaQip9awIRQO6aG0zqE5M+AIk8h2PCNtNGyQMOKjaYjtbdLxUpn/nbgcrNaMdlm6zd2534xOqFHzEKydndUZRmsDiIEOHBIfapVfIBFt3hz8Sb/kHZpwtQJUaBnIa9nbne2AvhnuR1T5Xk9juJh6myvtr3FNVbl0XZNaTX3Is1qO7w5wMlgcBRdVt+rSq/y+leTrzo5dqtyLz+lZFjJ/5n5GVGQDjzXAroGxxw99XhBJhcRmDTTJdyAkgQFgz/uyOkS5inC9nZPr8I9Iv/zbA5j1ChOgqSQXQRqmwbduxV2iWSzXtjZgPSvaPvcz6ksNWK3w/LhzmGmU4PLb1oNN+znOF/SLvmjciFCktp3ktl6CSFhSUqUG+SVxxul+NjZd5XY0uP71ptaGHWCXedOo4JClSWl35i94aCumFAKKyhvyUaSdyDjDiaJPmJ518fh2pgxuynrLBJW/3ucZek1AKb/BgmmjI7U22GZ6w72ILqdSKNWqRbWXqetdi+NXGiOFSG4jVF7jzzoq7HlmO607vsdRKYplihE305pEfdzvFBboN0eXP3aL9bB0uJjBspTgTcZh9Ocem ch2clkzp y+xrW98Gq0Pzp/tmhS4BwGoeUrLoGDea8rPOYO4lW3MCWPWgM4GNs1YGBfWwsMtcV4Isi0JwP3qbgqdBmR5QLDHkcmr5Kw7w4YWDhrq/N4aLt/yUZ6FxDzoLhjcNGEGaiDjg7xz99OWodh2wk4/XVDPxaKnY0PK8tJJHkEoMIrHtDHjiFkt6ggQ47/x2YVpGZpWOwCfDDj+8hX2p+r6CepN6XV1VJa/gGiWKLm7Jb3hheLI+2KQ22iqdO3F/biGSE7YyOtHm1I39e7Ouk6hmTgt9veavWKV8uTSpSNYQxJP9lJaG22nPNX6AlBFAXai5saXZMaZMHcbcvgXCkvAv0olQw9nEYSSuKPUDOVE6RQLYjCWlNIFvHx3bUkA== 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 Tue, Sep 05, 2023 at 11:58:17PM -0700, Saurabh Singh Sengar wrote: > On Fri, Aug 25, 2023 at 08:09:07AM -0700, Zach O'Keefe wrote: > > On Fri, Aug 25, 2023 at 5:58 AM David Hildenbrand wrote: > > > > > > On 25.08.23 14:49, Matthew Wilcox wrote: > > > > On Fri, Aug 25, 2023 at 09:59:23AM +0200, David Hildenbrand wrote: > > > >> Especially, we do have bigger ->huge_fault changes coming up: > > > >> > > > >> https://lkml.kernel.org/r/20230818202335.2739663-1-willy@infradead.org > > > > FWIW, one of those patches updates the docs to read, > > > > "->huge_fault() is called when there is no PUD or PMD entry present. This > > gives the filesystem the opportunity to install a PUD or PMD sized page. > > Filesystems can also use the ->fault method to return a PMD sized page, > > so implementing this function may not be necessary. In particular, > > filesystems should not call filemap_fault() from ->huge_fault(). [..]" > > > > Which won't work (in the general case) without this patch (well, at > > least the ->huge_fault() check part). > > > > So, if we're advertising this is the way it works, maybe that gives a > > stronger argument for addressing it sooner vs when the first in-tree > > user depends on it? > > > > > >> If the driver is not in the tree, people don't care. > > > >> > > > >> You really should try upstreaming that driver. > > > >> > > > >> > > > >> So this patch here adds complexity (which I don't like) in order to keep an > > > >> OOT driver working -- possibly for a short time. I'm tempted to say "please > > > >> fix your driver to not use huge faults in that scenario, it is no longer > > > >> supported". > > > >> > > > >> But I'm just about to vanish for 1.5 week into vacation :) > > > >> > > > >> @Willy, what are your thoughts? > > > > > > > > Fundamentally there was a bad assumption with the original patch -- > > > > it assumed that the only reason to support ->huge_fault was for DAX, > > > > and that's not true. It's just that the only drivers in-tree which > > > > support ->huge_fault do so in order to support DAX. > > > > > > Okay, and we are willing to continue supporting that then and it's > > > nothing we want to stop OOT drivers from doing. > > > > > > Fine with me; we should probably reflect that in the patch description. > > > > I can change these paragraphs, > > > > "During the review of the above commits, it was determined that in-tree > > users weren't affected by the change; most notably, since the only relevant > > user (in terms of THP) of VM_MIXEDMAP or ->huge_fault is DAX, which is > > explicitly approved early in approval logic. However, there is at least > > one occurrence where an out-of-tree driver that used > > VM_HUGEPAGE|VM_MIXEDMAP with a vm_ops->huge_fault handler, was broken. > > > > Remove the VM_NO_KHUGEPAGED check when not in collapse path and give > > any ->huge_fault handler a chance to handle the fault. Note that we > > don't validate the file mode or mapping alignment, which is consistent > > with the behavior before the aforementioned commits." > > > > To read, > > > > "The above commits, however, overfit the existing in-tree use cases, > > and assume that > > the only reason to support ->huge_fault was for DAX (which is > > explicitly approved early in the approval logic). > > This is a bad assumption to make and unnecessarily prevents general > > support of ->huge_fault by filesystems. Allow returning "true" if such > > a handler exists, giving the fault path an opportunity to exercise it. > > > > Similarly, the rationale for including the VM_NO_KHUGEPAGED check > > along the fault path was that it didn't alter any in-tree users, but > > was likewise similarly unnecessarily restrictive (and reads odd). > > Remove the check from the fault path." > > > > > Any chance this can make it to 6.6 kernel ? ping > > - Saurabh