Received: by 2002:a05:6a10:2726:0:0:0:0 with SMTP id ib38csp3544403pxb; Mon, 4 Apr 2022 20:40:41 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyalAWnDScKcg25XCSEyrAcQAO+PvtJ71K3uCTHgSctviXeodB9c6iocRTM4EJLsk/Z6FF2 X-Received: by 2002:a17:902:f68e:b0:156:b531:60cb with SMTP id l14-20020a170902f68e00b00156b53160cbmr1343464plg.49.1649130041322; Mon, 04 Apr 2022 20:40:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1649130041; cv=none; d=google.com; s=arc-20160816; b=ogUiGJ6R4hfGml2dzvDSQwlQ+0yb+LU1BbxqxC9tpcsGiy24oaSAHW7NSiu5PZxtvb oJnwLR7rhb3Evvs+R8ECajp+QCsXScL3uIh30Y3gzVqgGkbpfpUq+zvgjDE0yt7SpGng YTUqp5UD9JHYlXh1C43yi+OsPzFsGvy0z+ggQMgpfvM4sDTsSEx0K9KmYeOX18l5Z81i zHREeCHA+NfGmtAYwUIAKn2IBCorvIsS/0I4+e8giXXYZVeHTcTUywO0KlS5JuOlwgBU z2uLJlOOaNqtrREO1S4H2K5vdf7x24jy6b7SQHGqqEDq31BEZncGcvL6tmGKclKSF5+K VqTw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=y7CfRmOu2mFNhlP27BBXPAgEnRTv2JAfJlw4FzS8AkI=; b=fZNrd/ZibhyISwWC0fwChm6jDYlz3j13Z9xs/7JMA4cFJXTA/eJcfV/6OlOqJ8OTho JO7zfwLRwsP05e24flOI5LytonniJ0S86Oh0ml4De6XmgcSG6a9RL9tJcVzd0RnPasM3 I8ZhyKXQ9nZVeuw61imtLy4GHHQAXTew1Kqo0SOp3R5vvSWFciQXnf/+vcPq5ZnbgaOB 82xN6o8TKoqKbSPXgunGhjW4RQegRsaTcWJ5yhazsW3WAyUxG9tLCwMuOek0aFdfdSy4 J+FHn1RkSPIxPk9pv9q93LLXdAQFhlCNDBBWILhOtZWPfjeSsHxhiph4PqA2oTOgo1r/ G7CQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b="Z/ADUipX"; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id n4-20020a170903110400b00153b385c1a5si13118222plh.276.2022.04.04.20.40.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 04 Apr 2022 20:40:41 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b="Z/ADUipX"; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 7E33323E3CB; Mon, 4 Apr 2022 19:03:43 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229567AbiDECFa (ORCPT + 99 others); Mon, 4 Apr 2022 22:05:30 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47050 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229563AbiDECF0 (ORCPT ); Mon, 4 Apr 2022 22:05:26 -0400 Received: from mail-oi1-x236.google.com (mail-oi1-x236.google.com [IPv6:2607:f8b0:4864:20::236]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 70FA8135081; Mon, 4 Apr 2022 18:22:13 -0700 (PDT) Received: by mail-oi1-x236.google.com with SMTP id t21so11901663oie.11; Mon, 04 Apr 2022 18:22:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=y7CfRmOu2mFNhlP27BBXPAgEnRTv2JAfJlw4FzS8AkI=; b=Z/ADUipXSo6cCCoApgoWmuri8ib7Z2ZRmbnR54h8/VrIGaueK5QGu/WZtyWNFshPcu iAUxF22NOgckmUzcLG64u90kuydHGTVHt9OYXf690baDj9sOYSCj/jaZkbYXeWXHpMmB fAHEsMsaWg7XOguwyTv9/4z8MTuyMLKrHnwV08vQpUkIZUwgrbHKz3AVmSD3jtcNlM/x 0UinNkINbSntmhwlU0tlzyGj/QAvnPpxiM0jFhKpPSABVsY/8/XIx1H5kYyTNNFKFogR jNANubjJDZQhCftsvAm3pWtbim5rG5UTWikV3yCU0eXPRTt1v5MNXIOEz9cyijS6kP55 XDvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=y7CfRmOu2mFNhlP27BBXPAgEnRTv2JAfJlw4FzS8AkI=; b=LP6A0w0tgaMTEoQt/CdUYE9qBQGsBNo8Z8vLuS1o6ayplFYbJkgXfpjiEJBQxTFFi0 3mLGOevxCl0Boeg3O9XU3vXF7wA+GIxscRcvhwPdp82+jZz7tElpf/TfHhSrUHkXGAq6 WgGgq7VZny1ApersE8krX2x/FJIQ6kqDOyqAF5ffCi+SoLDRn/5m5xBynQ/a57xkMoVu XC7o8KVTX7GKXtgLrKFGYbGEFokgX6zSo8puN0Hq6WAlQ4JrCgcDu633lI+DhJUspOL+ NJOEzWTt4a1L0JgLrD2uqSD7mYT0h7tDkV9Ibz0shwdKw6HfMgp9ZSyVxRH+giCXTYV2 CRfw== X-Gm-Message-State: AOAM530rmVfmY6W3K8TkJ6OG7BU288KIniTRaJ6ZMm4jBTWEnAsoS/fX WUNj4NyB7KSdmCOF5NMT8j51dUJYBEwLoMu6qa2UkD5rZSc= X-Received: by 2002:a17:90a:5298:b0:1ca:7fb3:145 with SMTP id w24-20020a17090a529800b001ca7fb30145mr1036706pjh.200.1649119741666; Mon, 04 Apr 2022 17:49:01 -0700 (PDT) MIME-Version: 1.0 References: <20220404200250.321455-1-shy828301@gmail.com> In-Reply-To: From: Yang Shi Date: Mon, 4 Apr 2022 17:48:49 -0700 Message-ID: Subject: Re: [v3 PATCH 0/8] Make khugepaged collapse readonly FS THP more consistent To: Matthew Wilcox Cc: Vlastimil Babka , "Kirill A. Shutemov" , Miaohe Lin , Song Liu , Rik van Riel , Zi Yan , "Theodore Ts'o" , Andrew Morton , Linux MM , Linux FS-devel Mailing List , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RDNS_NONE, SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Apr 4, 2022 at 5:16 PM Matthew Wilcox wrote: > > On Mon, Apr 04, 2022 at 01:02:42PM -0700, Yang Shi wrote: > > The readonly FS THP relies on khugepaged to collapse THP for suitable > > vmas. But it is kind of "random luck" for khugepaged to see the > > readonly FS vmas (see report: https://lore.kernel.org/linux-mm/00f195d4-d039-3cf2-d3a1-a2c88de397a0@suse.cz/) since currently the vmas are registered to khugepaged when: > > I still don't see the point. The effort should be put into > supporting large folios, not in making this hack work better. The series makes sense even though the hack is replaced by large folios IMHO. The problem is the file VMAs may be not registered by khugepaged consistently for some THP modes, for example, always, regardless of whether it's readonly or the hack is gone or not. IIUC even though the hack is replaced by the large folios, we still have khugepaged to collapse pmd-mappable huge pages for both anonymous vmas and file vmas, right? Or are you thinking about killing khugepaged soon with supporting large folios? Anyway it may make things clearer if the cover letter is rephrased to: When khugepaged collapses file THPs, its behavior is not consistent. It is kind of "random luck" for khugepaged to see the file vmas (see report: https://lore.kernel.org/linux-mm/00f195d4-d039-3cf2-d3a1-a2c88de397a0@suse.cz/) since currently the vmas are registered to khugepaged when: - Anon huge pmd page fault - VMA merge - MADV_HUGEPAGE - Shmem mmap If the above conditions are not met, even though khugepaged is enabled it won't see any file vma at all. MADV_HUGEPAGE could be specified explicitly to tell khugepaged to collapse this area, but when khugepaged mode is "always" it should scan suitable vmas as long as VM_NOHUGEPAGE is not set. So make sure file vmas are registered to khugepaged to make the behavior more consistent.