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 7CB04C433EF for ; Fri, 18 Mar 2022 20:19:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E8E506B0071; Fri, 18 Mar 2022 16:19:14 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E3EB18D0002; Fri, 18 Mar 2022 16:19:14 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D060E8D0001; Fri, 18 Mar 2022 16:19:14 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0084.hostedemail.com [216.40.44.84]) by kanga.kvack.org (Postfix) with ESMTP id C12E86B0071 for ; Fri, 18 Mar 2022 16:19:14 -0400 (EDT) Received: from smtpin22.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 7428D8249980 for ; Fri, 18 Mar 2022 20:19:14 +0000 (UTC) X-FDA: 79258621428.22.83C0FB9 Received: from mail-pl1-f180.google.com (mail-pl1-f180.google.com [209.85.214.180]) by imf19.hostedemail.com (Postfix) with ESMTP id 0DBD71A0014 for ; Fri, 18 Mar 2022 20:19:13 +0000 (UTC) Received: by mail-pl1-f180.google.com with SMTP id h5so7871241plf.7 for ; Fri, 18 Mar 2022 13:19: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=HV4U7qntOGnpJQ2Afj++lgXG3IzP1EpW8jb1OgmKEbs=; b=cv/wFbgGRgnZTrAo2iSw2ZYNZUvLSvO2ykavsVExcgFHItqQBTyFH7XfiGSzuYmgwA Ed/JqSZs6k0xhbTvukrPZxEZWV4jv5BtS4zuCxqFqhs2oXgCojO8M1opGbEwTKSG4awU lhBbN+i+NnMlCgMprP9pR+cCkED5e/56cGEarkY/Ah0B68BqRb4VcQ/YZN/fWJ6ZzWgb sKicUq3R3HPPAKLMthT1J6DFsMHC27D8b35u/5XMiKH/TJ8FAXlzqZHDmEBL2uIpHWSa MnyPKyGIYzKEJiYv7difK79cDiFRCJnz5WPIfDR2pzRioPQmcDWorTSHCivvHfRSseRM TBSQ== 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=HV4U7qntOGnpJQ2Afj++lgXG3IzP1EpW8jb1OgmKEbs=; b=qZMAcUBLxW5mIwz9cIssfdG9dJXdk3CSILOcWujlgTgXwIG6fDDGX/hE8UdsOP9Rgk 2fbTSVEOn4kNXXQPiQSIIdHjhoP51147BZIpJ5vs20FLMQspVBeeyKzz60/3Biltn2jT FZNhf1wx38EKWUtdUE3wQjiNVWbwvKX8bNEpd2HIBlUQvjjJlM3bJb9BD4269mOTFTeE JuhNz+7IMaIb4dqtjwkoYuGnrUKx1E3sbPlYN2Lk1lwJW8evGx3TkDkHORN7lKgu3u7X gsH0lT5rfBRb5Qgovcma0RJZqfagM69cr7tOQ7TNNpk8U8xiNaNiIy/lJcH+ukaOrQKu HY0A== X-Gm-Message-State: AOAM530CwiD1gJ3PBqWzOYK9RrHZetGPDfF0qtcufSKjq0C++xj4Iif1 C6WYH3kh87+ndLVqM2l0K35V02Z1xajcAEBRtIo= X-Google-Smtp-Source: ABdhPJzS7VKxms885c65Z+VAIRBodeDJ9R0QcxFh8fU+8LTK7EQHr7jWlQVtwvzDdeaT2HcKmVDeVupzLGpfuzOqFwo= X-Received: by 2002:a17:90a:3906:b0:1bf:a0a6:d208 with SMTP id y6-20020a17090a390600b001bfa0a6d208mr23331916pjb.21.1647634752753; Fri, 18 Mar 2022 13:19:12 -0700 (PDT) MIME-Version: 1.0 References: <20220317234827.447799-1-shy828301@gmail.com> <20220318012948.GE1544202@dread.disaster.area> In-Reply-To: From: Yang Shi Date: Fri, 18 Mar 2022 13:19:00 -0700 Message-ID: Subject: Re: [v2 PATCH 0/8] Make khugepaged collapse readonly FS THP more consistent To: Matthew Wilcox Cc: Dave Chinner , vbabka@suse.cz, kirill.shutemov@linux.intel.com, linmiaohe@huawei.com, songliubraving@fb.com, riel@surriel.com, ziy@nvidia.com, akpm@linux-foundation.org, tytso@mit.edu, adilger.kernel@dilger.ca, darrick.wong@oracle.com, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org, linux-xfs@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 0DBD71A0014 X-Stat-Signature: bm9hnyeb7pmjgaach5unjhkb58rjptzr Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b="cv/wFbgG"; spf=pass (imf19.hostedemail.com: domain of shy828301@gmail.com designates 209.85.214.180 as permitted sender) smtp.mailfrom=shy828301@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-HE-Tag: 1647634753-25706 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, Mar 18, 2022 at 11:48 AM Matthew Wilcox wrote: > > On Fri, Mar 18, 2022 at 11:04:29AM -0700, Yang Shi wrote: > > I agree once page cache huge page is fully supported, > > READ_ONLY_THP_FOR_FS could be deprecated. But actually this patchset > > makes khugepaged collapse file THP more consistently. It guarantees > > the THP could be collapsed as long as file THP is supported and > > configured properly and there is suitable file vmas, it is not > > guaranteed by the current code. So it should be useful even though > > READ_ONLY_THP_FOR_FS is gone IMHO. > > I don't know if it's a good thing or not. Experiments with 64k > PAGE_SIZE on arm64 shows some benchmarks improving and others regressing. > Just because we _can_ collapse a 2MB range of pages into a single 2MB > page doesn't mean we _should_. I suspect the right size folio for any > given file will depend on the access pattern. For example, dirtying a > few bytes in a folio will result in the entire folio being written back. > Is that what you want? Maybe! It may prompt the filesystem to defragment > that range, which would be good. On the other hand, if you're bandwidth > limited, it may decrease your performance. And if your media has limited > write endurance, it may result in your drive wearing out more quickly. > > Changing the heuristics should come with data. Preferably from a wide > range of systems and use cases. I know that's hard to do, but how else > can we proceed? TBH I don't think it belongs to "change the heuristics". Its users' decision if their workloads could benefit from huge pages or not. They could set THP to always/madivse/never per their workloads. The patchset is aimed to fix the misbehavior. The user visible issue is even though users enable READ_ONLY_THP_FOR_FS and configure THP to "always" (khugepaged always runs) and do expect their huge text section is backed by THP but THP may not be collapsed. > > And I think you ignored my point that READ_ONLY_THP_FOR_FS required > no changes to filesystems. It was completely invisible to them, by > design. Now this patchset requires each filesystem to do something. > That's not a great step. I don't mean to ignore your point. I do understand it is not perfect. I was thinking about making it FS agnostic in the first place. But I didn't think of a perfect way to do it at that time, so I followed what tmpfs does. However, by rethinking this we may be able to call khugepaged_enter_file() in filemap_fault(). I was concerned about the overhead in the page fault path. But it may be neglectable since khugepaged_enter_file() does bail out in the first place if the mm is already registered in khugepaged, just the first page fault needs to go through all the check, but the first page fault is typically a major fault so the overhead should be not noticeable comparing to the overhead of I/O. Calling khugepaged_enter() in page fault path is the approach used by anonymous THP too. > > P.S. khugepaged currently does nothing if a range contains a compound > page. It assumes that the page is compound because it's now a THP. > Large folios break that assumption, so khugepaged will now never > collapse a range which includes large folios. Thanks to commit > mm/filemap: Support VM_HUGEPAGE for file mappings > we'll always try to bring in PMD-sized pages for MADV_HUGEPAGE, so > it _probably_ doesn't matter. But it's something we should watch > for as filesystems grow support for large folios. Yeah, I agree, thanks for reminding this. In addition I think the users of READ_ONLY_THP_FOR_FS should also expect the PMD-sized THP to be collapsed for their usecase with full page cache THP support since their benefits come from reduced TLB miss.