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 3265FC433F5 for ; Mon, 9 May 2022 20:34:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 479B96B0072; Mon, 9 May 2022 16:34:24 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 428766B0073; Mon, 9 May 2022 16:34:24 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2C9886B0074; Mon, 9 May 2022 16:34:24 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 1A5526B0072 for ; Mon, 9 May 2022 16:34:24 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay12.hostedemail.com (Postfix) with ESMTP id DD33012126B for ; Mon, 9 May 2022 20:34:23 +0000 (UTC) X-FDA: 79447357206.15.5A11F15 Received: from mail-pl1-f179.google.com (mail-pl1-f179.google.com [209.85.214.179]) by imf20.hostedemail.com (Postfix) with ESMTP id D3A4E1C00A2 for ; Mon, 9 May 2022 20:34:14 +0000 (UTC) Received: by mail-pl1-f179.google.com with SMTP id n18so14948373plg.5 for ; Mon, 09 May 2022 13:34:23 -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=Y8q8hS13mezAfTrD0NxBCh3WW3DjGFdjsDczU3OI0oc=; b=G5N/JMPIwivQiHptH5/whFI3nH4TMi31rra93rxi48Fc3Uwhx0zRuO75G/xD/6fgRs mUuL2ZNO9UklkK4Gf06a7ully8/IGidEPjSavVIQFd37zoT33G47do+mumd1Ac7oRDXv pehs4xfS35G/N0w0Hte9MnqBAThy7H4lZEykJ95yBGiZ23DzbUDkGyKec3GLyr5IVhgc fNdmZp3F5l4oNlyCjEzPayh8zujw7LIfgmAlVXI+N4IFytFiD6uuNDkPtCZy/tDSrgk9 g5t84ScsBytD7BrxvxHl070nnGJlv0eDiMUkGFeCXCW0O/cYp3LjbbcYXAmUbvQQcOmX YVFQ== 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=Y8q8hS13mezAfTrD0NxBCh3WW3DjGFdjsDczU3OI0oc=; b=p867Wt2HfjhPWA1Ln6v8o+6dNW9UZpjrWcT5Tk3cIEvAQflKu35k+5CZmxMIpSPXOb 772k8rylzFJxSwWHb3+NTDB8Zrv2M+IVAlMEQ6WOKO+QRT6DzAg6sTZb656dXCHBF3+K e83np88PEWJVmyn1VcB/xOGZWAw/TMYQpNI8DpHBunh26E3V8ck7OzbSuRiCz7KbpcST jn2B3uhLxbsovV+Bw3ZRWCvFKtzey4AVgdg3YjhYxiQHwOdEeJRRy6+cPXGGTgfdG+l4 GD01eccmzCRGwz6Krlb+FtAROEgdcs9GpWqmY4gLM2C+AJAthgtcDQEpqoczLuGyZVg8 NfIA== X-Gm-Message-State: AOAM531aAwpoG1PizOxhCXrR+YquNsFDhl75ZS8x2WZ+aGDqfS70gRUI 7LNi2K+t6nUNFD3y1zKMfGoTl31tGg6XoAxgD5g= X-Google-Smtp-Source: ABdhPJx/s8hXrP/qllB2VLxqIOnghx9MB0AOjfslleJuVeqgRcuT487dkChNAInW3ZagiVKZQ3utmLNKaHRgzV0pA/I= X-Received: by 2002:a17:90b:1b52:b0:1dc:54ea:ac00 with SMTP id nv18-20020a17090b1b5200b001dc54eaac00mr28126284pjb.99.1652128462376; Mon, 09 May 2022 13:34:22 -0700 (PDT) MIME-Version: 1.0 References: <20220404200250.321455-1-shy828301@gmail.com> <627a71f8-e879-69a5-ceb3-fc8d29d2f7f1@suse.cz> In-Reply-To: <627a71f8-e879-69a5-ceb3-fc8d29d2f7f1@suse.cz> From: Yang Shi Date: Mon, 9 May 2022 13:34:09 -0700 Message-ID: Subject: Re: [v3 PATCH 0/8] Make khugepaged collapse readonly FS THP more consistent To: Vlastimil Babka Cc: "Kirill A. Shutemov" , Miaohe Lin , Song Liu , Rik van Riel , Matthew Wilcox , 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-Stat-Signature: ww36cqfpozc6zepftjeka1iisb31o5z6 X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: D3A4E1C00A2 X-Rspam-User: Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b="G5N/JMPI"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf20.hostedemail.com: domain of shy828301@gmail.com designates 209.85.214.179 as permitted sender) smtp.mailfrom=shy828301@gmail.com X-HE-Tag: 1652128454-25997 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 Mon, May 9, 2022 at 9:05 AM Vlastimil Babka wrote: > > On 4/4/22 22:02, Yang Shi wrote: > > include/linux/huge_mm.h | 14 ++++++++++++ > > include/linux/khugepaged.h | 59 ++++++++++++--------------------------------------- > > include/linux/sched/coredump.h | 3 ++- > > kernel/fork.c | 4 +--- > > mm/huge_memory.c | 15 ++++--------- > > mm/khugepaged.c | 76 +++++++++++++++++++++++++++++++++++++----------------------------- > > mm/mmap.c | 14 ++++++++---- > > mm/shmem.c | 12 ----------- > > 8 files changed, 88 insertions(+), 109 deletions(-) > > Resending my general feedback from mm-commits thread to include the > public ML's: > > There's modestly less lines in the end, some duplicate code removed, > special casing in shmem.c removed, that's all good as it is. Also patch 8/8 > become quite boring in v3, no need to change individual filesystems and also > no hook in fault path, just the common mmap path. So I would just handle > patch 6 differently as I just replied to it, and acked the rest. > > That said it's still unfortunately rather a mess of functions that have > similar names. transhuge_vma_enabled(vma). hugepage_vma_check(vma), > transparent_hugepage_active(vma), transhuge_vma_suitable(vma, addr)? > So maybe still some space for further cleanups. But the series is fine as it > is so we don't have to wait for it now. Yeah, I agree that we do have a lot thp checks. Will find some time to look into it deeper later. > > We could also consider that the tracking of which mm is to be scanned is > modelled after ksm which has its own madvise flag, but also no "always" > mode. What if for THP we only tracked actual THP madvised mm's, and in > "always" mode just scanned all vm's, would that allow ripping out some code > perhaps, while not adding too many unnecessary scans? If some processes are Do you mean add all mm(s) to the scan list unconditionally? I don't think it will scale. > being scanned without any effect, maybe track success separately, and scan > them less frequently etc. That could be ultimately more efficinet than > painfully tracking just *eligibility* for scanning in "always" mode? Sounds like we need a couple of different lists, for example, inactive and active? And promote or demote mm(s) between the two lists? TBH I don't see too many benefits at the moment. Or I misunderstood you? > > Even more radical thing to consider (maybe that's a LSF/MM level topic, too > bad :) is that we scan pagetables in ksm, khugepaged, numa balancing, soon > in MGLRU, and I probably forgot something else. Maybe time to think about > unifying those scanners? We do have pagewalk (walk_page_range()) which is used by a couple of mm stuff, for example, mlock, mempolicy, mprotect, etc. I'm not sure whether it is feasible for khugepaged, ksm, etc, or not since I didn't look that hard. But I agree it should be worth looking at. > >