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 B8C01C3DA58 for ; Thu, 17 Aug 2023 18:29:49 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4BF7D28004A; Thu, 17 Aug 2023 14:29:49 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 46F54940009; Thu, 17 Aug 2023 14:29:49 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 336DE28004A; Thu, 17 Aug 2023 14:29:49 -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 1FA84940009 for ; Thu, 17 Aug 2023 14:29:49 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id E1E1EA077E for ; Thu, 17 Aug 2023 18:29:48 +0000 (UTC) X-FDA: 81134435256.13.7943817 Received: from mail-ed1-f50.google.com (mail-ed1-f50.google.com [209.85.208.50]) by imf18.hostedemail.com (Postfix) with ESMTP id 054331C002E for ; Thu, 17 Aug 2023 18:29:45 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=dc7ZJnjD; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf18.hostedemail.com: domain of zokeefe@google.com designates 209.85.208.50 as permitted sender) smtp.mailfrom=zokeefe@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1692296986; 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=WkAgdDaWL5fNhn+jmFmfbxUk8CggEcM/uCFAi9gM/RM=; b=YG9VdywZW9DBV1GvvxSKwunStOUbk0ROaYbrkcTWGX5my0O/EfkaTBi8XliO4daewv1w8z LSB6YQDqK/oaTFWxoi5miNTDNbw44sj3YZaioXkf2xsDPzNFDXPMP704U1A3oUxfnItC3R 7QnU1AJssA8iOv7NrAQiyHAwkPVF9xk= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=dc7ZJnjD; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf18.hostedemail.com: domain of zokeefe@google.com designates 209.85.208.50 as permitted sender) smtp.mailfrom=zokeefe@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1692296986; a=rsa-sha256; cv=none; b=gAgT5OIvTi9FtBf8fLHSTnDCOjBRZ3VeIJXyY/ayU8cxtFeedbSIgffDSkD3qjTgPQSKGy qVKkLv5nEXCCTg/WDOh4XuxMnkwgILo+8Z9AVd+7A4VN9xknilVK8zvGRUEtP8TZEga7di Yqs4MCeCelhX3zwtIamZXH6LRbwk/yM= Received: by mail-ed1-f50.google.com with SMTP id 4fb4d7f45d1cf-5257d67368bso1650a12.0 for ; Thu, 17 Aug 2023 11:29:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1692296984; x=1692901784; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=WkAgdDaWL5fNhn+jmFmfbxUk8CggEcM/uCFAi9gM/RM=; b=dc7ZJnjDNn02b6xO/Z1bwoGZ3PD9YuY0apXBEFZl6w+mtfqB8N9amVcCsfKmgS3NSy 847mhWHHFfAit/4LRpbfu66Uiri9GQLt9SuIbOSRJ0OdRXHHiSctyuQZq/ltoaGjOlIT +iveTm+wL7zoltTBdQYgMnGJVxfNddqF5rFdR/dtfi38iDUUKA7fx7NWhnnqefQIi1u7 RfoYf774AEPpsCoeyopmAjTYF2P0SY+XFYiDmdGBz8bJ/m7Yo29ar6tWtVqjhlrqX83A mEy8XeunfSC6tOAIPS230L3XynUWyiQ9f2lJbrKtln+K/pej/PNIkwR8wFynLyucDE4m Nq1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692296984; x=1692901784; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=WkAgdDaWL5fNhn+jmFmfbxUk8CggEcM/uCFAi9gM/RM=; b=Jc6vypcNOexFz9dSF0IKrv5L5cPq9cphjUZzEmo5dRIlow8QcTqUdpTy3s7L/V9ju5 Qp5oXr1jaodw/zON810R2CglD4NIG6bYAro7mQKuP5r8xlCKzGa9xhJENcUxPcD0hiRa FevtQLO2M0YfCse6A6URWMzEZAqhx0IkHndZ6Qf/qGVvFFOb/TjPwtNVW7tS0XZDwJOE pKdiJvoiu2WmWOq+vAZANkhGgvqFc3MmadmKce/y9ajQfxPDKPD9zlhVF8d/W5KG+2mQ EBOHm1Fn4XElMdtyuXhiDvj+5EWfLVvj1QwGUs+XsFudIhi3XYSHlxGnhIN0hShmRAzs 4S8A== X-Gm-Message-State: AOJu0YxnRvZqhnSLwCa3Tsu4nJzMdmdANBjdEV4WrqGgYdkeLRbfHYFf ruo90Xk2sF5Xrupq1xtyyNO/SSrdWYJ3AAfZ4mu5Vg== X-Google-Smtp-Source: AGHT+IEtIsv+ixBsWLC3dA9EiG1urEOCBhPubzen5tiXTL1APEp6KTLUispQNz5tnl3OlQYlWojaH/Ghb4hu2UiZfW4= X-Received: by 2002:a50:d4da:0:b0:523:193b:5587 with SMTP id e26-20020a50d4da000000b00523193b5587mr15712edj.6.1692296984186; Thu, 17 Aug 2023 11:29:44 -0700 (PDT) MIME-Version: 1.0 References: <20230812210053.2325091-1-zokeefe@google.com> In-Reply-To: From: "Zach O'Keefe" Date: Thu, 17 Aug 2023 11:29:06 -0700 Message-ID: Subject: Re: [EXTERNAL] [PATCH] mm/thp: fix "mm: thp: kill __transhuge_page_enabled()" To: Yang Shi Cc: Saurabh Singh Sengar , Matthew Wilcox , Dan Williams , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 054331C002E X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: mzdyeaxsc195rqqr95oyssbt1ais86gr X-HE-Tag: 1692296985-866284 X-HE-Meta: U2FsdGVkX1+bzh9zPlDpwY/F+xvVovw6nuw9pRojzTXkHQs1gaI+M5ooulWKS760+n5iVBDYPA5jFNmEpEtDOdj/k8DazjiVKLxGSTZYi1Er16P8eBlZlhANUQwZ3F2lCrlHLi5VCs9XMuRaw7+YlpvP/k2Q4LpoSWN6TvLfuhgqleI7jQVBpatMIY7RvuyIQq3DCzMdoAyCPIeFDEnxPPNXtqZuXY0b7fNPTWNcvSxzcbDSeMiW2XIoSQ21rXDoxtTmgYLhEFsrtrHp6caSmANSyF9Z+oRqCpp20OpBzsNwz3KBupQLfeUhpVErbRWeKN3FZ8iUQ2/7yKLN4RjZs6Cwpp+DqJah/yUChvszgFaYjRzDgkMCfwTL7L6zwp3NUEk4ATfSSimHznwiGLxZdpUIkWattmLf3OTNHQ+9dhdgv4aTv8peGOBKW1AyFiD9NCXNEEfOvTqpofFLgbXB5hUvexDzK8U11wLTfSN8Kwge6+SuLrH+UYk2OpHU/0Nlsj7t3M17gpCnHLy6ldpv553azoAa4eKZY7ADU0QceuSv5WZxjVk0KGcQ6L31Rhshzg/PRCDyMHP2/wdLRXVvx5qVyGqj89/TX512DVvKTyCrjNPdA3SXcbvS3V6qclyaJDLXhcHdXt7qlyWuM2bzyGn2Fux7V2EPZbnj4Spq7yYKfoU8X6O43qvMatzg5mEOFi10WZm8wj8XuxPeJQkl9dZJ73FH8BnjbmMTs6urXW4dZWM7UqpRhMMZrWndPNwag040U5wxTEZ3VXRUO6MSrN19g0b+lWUJwvMrveOhOrzNYbY2eEoNhFyAYVABshnVI2xq3wui3PzZXZnlAtII5LVITEh+fiZcK30uVT2GNuipg+dC086QqAWa8rt7PsMRQIj4N7sMnR2CgrFydy9lqhpFzeQ6PRlBX/4WgOIw4Vv+u5s7GI2qSbER5qn2jR0oZwQ51Rv707M6kgzW0Nk Pz8LOqrj InjLge1PoFpbUr3Ewm1RNNL5Uvw5z1gN8KZeVOkRWutzzWmvWIajlUkouNXG2YVP+VXDQ7m/1k3EI66KVmAtO03MK2FUMgLbMQX6IUFO4+cyVwajGFe6k9dDT7AzmcfG7r2koeycVSi5R9lmvnsb4fMXpQJU8LsW8rq+peNO0xgew+iTPn0XOFVKBTVWR33JMcoIHJHRcZcm3K4HxFqNii6ps9c26LQ5nShxkQP8t+CAiIsGKwQASiuL8FKza1n7oM1lDypCTwkIWjrDG0p1U6yHDjMqgHlFR2AUoeGSrYaQexalEUHnK4O93i8thEWPExf+4HMyBDPViAo4EqVfo6tMtjJOiJQec/b4YUpNCcvzgoJc= 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 Thu, Aug 17, 2023 at 10:47=E2=80=AFAM Yang Shi wro= te: > > On Wed, Aug 16, 2023 at 2:48=E2=80=AFPM Zach O'Keefe = wrote: > > > > > We have a out of tree driver that maps huge pages through a file hand= le and > > > relies on -> huge_fault. It used to work in 5.19 kernels but 6.1 chan= ged this > > > behaviour. > > > > > > I don=E2=80=99t think reverting the earlier behaviour of fault_path f= or huge pages should > > > impact kernel negatively. > > > > > > Do you think we can restore this earlier behaviour of kernel to allow= page fault > > > for huge pages via ->huge_fault. > > > > That seems reasonable to me. I think using the existence of a > > ->huge_fault() handler as a predicate to return "true" makes sense to > > me. The "normal" flow for file-backed memory along fault path still > > needs to return "false", so that we correctly fallback to ->fault() > > handler. Unless there are objections, I can do that in a v2. > > Sorry for chiming in late. I'm just back from vacation and trying to catc= h up... > > IIUC the out-of-tree driver tries to allocate huge page and install > PMD mapping via huge_fault() handler, but the cleanup of > hugepage_vma_check() prevents this due to the check to > VM_NO_KHUGEPAGED? > > So you would like to check whether a huge_fault() handler existed > instead of vma_is_dax()? Sorry for the multiple threads here. There are two problems: (a) the VM_NO_KHUGEPAGED check along fault path, and (b) we don't give ->huge_fault() a fair shake, if it exists, along fault path. The current code assumes vma_is_dax() iff ->huge_fault() exists. (a) is easy enough to fix. For (b), I'm currently looking at the possibility of not worrying about ->huge_fault() in hugepage_vma_check(), and just letting create_huge_pud() / create_huge_pmd() check and fallback as necessary. I think we'll need the explicit DAX check still, since we want to keep khugepaged and MADV_COLLAPSE away, and the presence / absence of ->huge_fault() isn't enough to know that (well.. today it kind of is, but we shouldn't depend on it).