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 2583BEB8FA5 for ; Wed, 6 Sep 2023 06:58:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9C384940008; Wed, 6 Sep 2023 02:58:21 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 949848E0014; Wed, 6 Sep 2023 02:58:21 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7EA53940008; Wed, 6 Sep 2023 02:58:21 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 692428E0014 for ; Wed, 6 Sep 2023 02:58:21 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 46D90A08AA for ; Wed, 6 Sep 2023 06:58:21 +0000 (UTC) X-FDA: 81205268802.18.D468F9D Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by imf29.hostedemail.com (Postfix) with ESMTP id 66E4B120013 for ; Wed, 6 Sep 2023 06:58:18 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=linux.microsoft.com header.s=default header.b=d23dPdUV; dmarc=pass (policy=none) header.from=linux.microsoft.com; spf=pass (imf29.hostedemail.com: domain of ssengar@linux.microsoft.com designates 13.77.154.182 as permitted sender) smtp.mailfrom=ssengar@linux.microsoft.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1693983498; 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=ZIPYZd5pdchX9W8xrgtG5lbsRV2RcT30reKJRBwH/lA=; b=OjUruXWtkQkvU83rJNjZIrc0G+vtxoVK212SIPlApA2WVgSqIwNrWJma0Q2fvy/+SNHLyh aWAcQGwYIYGKrzLzbX7MhHN2gMhWY065dtP+VaCUy3aHqrvLhtcusoNnv6idVID0UwANKm Nu+hXsEHA1V/Q3f+6fvEhP3ZB7oXFGs= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=linux.microsoft.com header.s=default header.b=d23dPdUV; dmarc=pass (policy=none) header.from=linux.microsoft.com; spf=pass (imf29.hostedemail.com: domain of ssengar@linux.microsoft.com designates 13.77.154.182 as permitted sender) smtp.mailfrom=ssengar@linux.microsoft.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1693983498; a=rsa-sha256; cv=none; b=K717pBRITkN4LVF1uodJoGXzz5EuTGRODSOplJQ4taBz6531h/DbBxM/9PxpRyQSNwUh/u 1R3ffWSNf5brAG4rboEhF340o+XzQdnfNhO5IWYK9RzU7GeLzbBzX1JMWe/dYMrcwlZZq7 bxkcAGOJYiTQVZayOLcqLR2zoAByeFA= Received: by linux.microsoft.com (Postfix, from userid 1127) id 188FD212B18B; Tue, 5 Sep 2023 23:58:17 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 188FD212B18B DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1693983497; bh=ZIPYZd5pdchX9W8xrgtG5lbsRV2RcT30reKJRBwH/lA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=d23dPdUVFw5wM1U3HMzSFsiJgJENPnmtUUR1mMgLxqT+7RJAjTLdurY2OV6nB6/N4 plZJOA8c2lnHZhyuy6XdTsK5gb6PahRR/SHUdOg8rGxDAtos+v/IedoJSBFXzdsNTu xpA3fPtlBggI3rby3CDbpHeAV7/LdUI+ugJbq3qQ= Date: Tue, 5 Sep 2023 23:58:17 -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: <20230906065817.GA27879@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> References: <20230821234844.699818-1-zokeefe@google.com> <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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Rspamd-Queue-Id: 66E4B120013 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: eyuj38um75mk5nd7hi9eoz164drjboik X-HE-Tag: 1693983498-993088 X-HE-Meta: U2FsdGVkX18micZpI5CJJxRrnDmsq+ZYTHcUJ1F5vqJFieiCNLqQwn8/GR2Hsg6JvLFAycyhCYahmOdv+1Hcu5LXQPH/axDcZY2kLmtVQJ7J7h7rc/B0BlW0mEOfjIVZLWkXgNuabZe/gmBE5J12IJBBDsqJWZ0rsCF5uWZT4ozODDS8jAJY/re3yMP1NnR10o0SIraVdpY7kCMKp8Gx1XqX3mCorHcmGfnmop3fnBL44QhcmFP3XDlEvq51cj90rQ/OIcV0Wq25mvUI79beQPuvlZ11j9s8UR6khvOeupDjq6lsX5xxW0oNMVXI1WLC/2bLvrAqIvj8uBpn6Ox880rnficHv1T0q2vfodfyVXI/89QduoRZjB9tJTAJTeaFxjMtAYSS6IerByltrqsYB3ez/wr028BOliGxXp8s+F4lTLW7rbiJAebl1+Ybnz8AGj1G5KgxwRvOt9dACQ/D/y4U4BvcxCATNKBhkEvyUlXPnCkHhYFzap030MPHl2qjXer9YgskCJANlad8rtRUT7y3vlIfDWGsRh9F5gcR9Hc2r4I3IfXfdTHzqOqv/qIxNaHQl+2fuPu/C8To3jqbi2V326e3FbElv0elGLmuQe7xh1/EmSRcprUT1th0dyrryaUNIz62a4fTL/YN2akFtRVIMqlT2xwWa2JBJ/7UiKRUI8Y7Yjx63jm7G8gPVZkTh7aq2zlJKBWxHZ1O6XGjePSFS3l8dm0UWGVwLcZluX4u25sMdxS+y2YKjLWI3N5QVOETW0f6MS8IFqFuOHdoMz4fYd8hH1R4NY7vGRIpNPLxDwQEgNPo/3JIHJyn93QjywdTlDP7nCMskczGbojOJnutRFEStjyl8kO14qTc+81S/Lb7LMPxp5UldjuDeoua2gBFkro4VwGGVhRJL6TVFB2Rc2mSmLyLGpFfLn95HMKUNzlTHwa0mjM+Z/DzT6OTLumGVOvB8HUsVdpEeBN U4NhPgfX uBLiQXINAUljWTgalyPNvtnXXum+kdvmVS4DHlJuPHkL5IgVUtQt9A5REYC0Xf95baBkVYc/TyrvZoQjpu4XBF6BdLyZW53znPlk1EbRTZJWeyKt2W4scMsiQc6M4F/lb6UVgRJeo+N6ToMUy4oHN4EPsdVfpHKUNhw7VdG1ylmP9dB6b7Ae0pO1NpU2veu7UqVHwiAY+v0IV20VzRHQ8aQeVZwmq8SaHUSJYyhnIAxjkNDCf9UNCci8oUAw2pfRAMicnHtc5SUv78Pb5BABmBup8h3xoKmb/Gz+qvVE7PBe2H54tpW7Pzw4uZBROsYcDYJLEeWBy4DdjGHgySt9VeiwPC4eS+7c4X0pmchT31i8rbKkfTLRqgcXRhQ== 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, 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 ? - Saurabh