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 3E8CDC433F5 for ; Tue, 24 May 2022 22:43:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AF7748D0003; Tue, 24 May 2022 18:43:37 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AA6878D0001; Tue, 24 May 2022 18:43:37 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9B77B8D0003; Tue, 24 May 2022 18:43:37 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 8E3188D0001 for ; Tue, 24 May 2022 18:43:37 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay13.hostedemail.com (Postfix) with ESMTP id 6FFFF60B1C for ; Tue, 24 May 2022 22:43:36 +0000 (UTC) X-FDA: 79502114832.25.3BC160B Received: from mail-lf1-f53.google.com (mail-lf1-f53.google.com [209.85.167.53]) by imf22.hostedemail.com (Postfix) with ESMTP id 4662CC00EC for ; Tue, 24 May 2022 22:43:31 +0000 (UTC) Received: by mail-lf1-f53.google.com with SMTP id p22so33177962lfo.10 for ; Tue, 24 May 2022 15:43:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:from:date:message-id:subject:to:cc; bh=DrGGDdvEKm7mv+0NgHfuJNNKaJyDCiyVHzp84ldMe9E=; b=kYaFbREIyIZpemvrIBCsf8iU0P1U82DAPxcx7Jtzq73f4ySogBYaqzeh68Dljx/Zyc BA15wcoVgSPZrlXuAcR3ovAl6WVjL4ECz4NwUFXgjmSJ+LgjEKt+zlPLA6Dv7aDRiWr1 hhkGVsid6ZNf2UsrnwPOdM/8x6mlK/hEe7GRXzQW4ey1SegVUjTcGh7yFOK3TSry51+Q OOOkwqak4U5v5ZTFvS2sv9vPUZrERkMJOxx2bORLaYc96EgvPW+gzokam1tVhFKKJw8u 5qtOtGnvfKnkmbn8qkYmCYVV3G+ULcOgHLCYOcqG59Qc3WuQeuy+oiwxlPjOPYUSATPc cHBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=DrGGDdvEKm7mv+0NgHfuJNNKaJyDCiyVHzp84ldMe9E=; b=LBz4EQP2Jbc1YWhEhCv0hCU4G5kpg1eKHy0UJdsuxY/sBmGvxnoycy6fZHPkaNvXvQ Vt9BtLU8C5qoYIdYWEgvDwK+IL+HaWqwCwyoWVIrkb7DCFXtt9OLuuKFg8owEu00IoQc PMv5wYZz4kx4xnMzl7xuVoMLOT7ipo2qThBx3H8ImsiOPTj26iKQFWoqADb3SvZgCTfO LCsgY9bdRTLfQMC7EGnzZJQ8o9/yBWAaoeZQvj8mUAWAem9VA0Ub2hLngmI/tI4ikW5u NmHdld6jeX27E0RDknreMRughluf0yhWOxYJ5ID69viOU3xIFd5qS5q+NzmUj/HEBBl0 P4Sg== X-Gm-Message-State: AOAM533RFz/6FSReFOSzTaqGpbOcLhHo4bza47SwBU683xK6Y+PGrwQe /WJeIm7TL+2SayYkQwrEWeiTRVsHwePpYHTK8NvpOQ== X-Google-Smtp-Source: ABdhPJyHwMaFJC41MYvVr9aTovXzrGWq8d7GhXC/3OGuTFA2DwDRXebsvASslL0A+L5Ppcmc9RdfhOGaZL83o5yVBms= X-Received: by 2002:a05:6512:a84:b0:478:6ead:216e with SMTP id m4-20020a0565120a8400b004786ead216emr8647478lfu.159.1653432212017; Tue, 24 May 2022 15:43:32 -0700 (PDT) MIME-Version: 1.0 From: "Zach O'Keefe" Date: Tue, 24 May 2022 15:42:55 -0700 Message-ID: Subject: mm/khugepaged: collapse file/shmem compound pages To: willy@infradead.org Cc: David Rientjes , "linux-mm@kvack.org" Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4662CC00EC X-Stat-Signature: aj5shcw1j66tyqudgqkyoqnczoddai1a Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=kYaFbREI; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf22.hostedemail.com: domain of zokeefe@google.com designates 209.85.167.53 as permitted sender) smtp.mailfrom=zokeefe@google.com X-Rspam-User: X-Rspamd-Server: rspam06 X-HE-Tag: 1653432211-126418 X-Bogosity: Ham, tests=bogofilter, spamicity=0.073610, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Hey Matthew, I'm leading an attempt to add a new madvise mode, MADV_COLLAPSE, to allow userspace-directed collapse of memory into THPs[1]. The initial proposal only supports anonymous memory, but I'm working on adding support for file-backed and shmem memory. The intended behavior of MADV_COLLAPSE is that it should return "success" if all hugepage-aligned / sized regions requested are backed by pmd-mapped THPs on return (races aside). IOW: we were able to successfully collapse the memory, or it was already backed by pmd-mapped THPs. Currently there is a nice "XXX: khugepaged should compact smaller compound pages into a PMD sized page" in khugepaged_scan_file() when we encounter a compound page during scanning. Do you know what kind of gotchas or technical difficulties would be involved in doing this? I presume this work would also benefit those relying on khugepaged to collapse read-only file and shmem memory, and I'd be happy to help move it forward. Thanks for your time, Zach [1] https://lore.kernel.org/linux-mm/20220504214437.2850685-1-zokeefe@google.com/