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 5E405C433EF for ; Wed, 29 Jun 2022 20:43:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B7B5D6B0071; Wed, 29 Jun 2022 16:43:41 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B2B298E0001; Wed, 29 Jun 2022 16:43:41 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A1AAE6B0073; Wed, 29 Jun 2022 16:43:41 -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 9586C6B0071 for ; Wed, 29 Jun 2022 16:43:41 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay11.hostedemail.com (Postfix) with ESMTP id 5E56C80AB2 for ; Wed, 29 Jun 2022 20:43:41 +0000 (UTC) X-FDA: 79632449442.29.F155E35 Received: from mail-oa1-f50.google.com (mail-oa1-f50.google.com [209.85.160.50]) by imf14.hostedemail.com (Postfix) with ESMTP id 3D0D710001D for ; Wed, 29 Jun 2022 20:43:38 +0000 (UTC) Received: by mail-oa1-f50.google.com with SMTP id 586e51a60fabf-101e1a33fe3so22999678fac.11 for ; Wed, 29 Jun 2022 13:43:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=unn1KvNAzE9h6f0ulBz87PP0Kg2idELqqTph3Y3vuSE=; b=hiOezGyLtPvPG3RDVeyodumlKjyu6i8GP435RvkplP5j2ujmBwK9l9yY4TAMBiASns PjLR0WHY0CqCIgGHhf0d38dbtIk0k9gGEPP46R4+y+lmAhun708c9MuRmbhMcfRz4nJM qYmIbgsmTwxnfFECI75Ez7CEMPEn26nMZ0cBbvXltUTG+lZADVvgB9v1Y42i/QLFYBS4 uMpDdQq948hn78KTa5jRvqW2IExmJcaRFXSkIyRPxVrRaexJmSNwLP7gLDyaE8J1Tskv Zj1Jbcw3hw6toQNP/JofJlrp1HOwsAjavYdeGNLZxEZb6reYk/fNyGwOGhbkfq9Jhuqb ncgw== 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=unn1KvNAzE9h6f0ulBz87PP0Kg2idELqqTph3Y3vuSE=; b=bA5lV+yt3x3LeZUzJuJcn8LVq21fnh0jCKnx+PoDdSL1rD1shx5K6VhYAygFXJwE0R 5EtWkWyPow59e6Sf47fLjOYZ7+YR9n1MFhub7QFkngFbmkvoJ6NPplTwMxJpwfVUl1IX maqi8OWlYyAVmgD4aLIsBv/35L/CDtAIzrIxFaC8SVs6dbxFgfRLhUEhy9f592lo+Z9E uK8nakfiILotJXsn58252ySdYH1yhAa/Xxkw3gK2wVvq/PgB3j2gqbHjGCdbi4kitTe7 BFbmDVkxbx18c8Hc3DJg+EPSX5p3s/S9q3Jx3zQlnJRvIqWWMr0/lWmszJcGJrxvtlPr 8fIw== X-Gm-Message-State: AJIora9pBsGZSg1oZXJFcS+CO2F/limeVq9lw72lTUz2Nfihhgo8ie/C top8NqHAT0cQMGudc8k+0MKHSxRI0vB2mUa1aiJ7mQ== X-Google-Smtp-Source: AGRyM1va/UYVDgt5A5eaIROjgSZkupOlYxX5l98H1Gv8v8tT1sctn8bifFnJy/CKycjZElxrazAXo2FlPDpf3h5GPNo= X-Received: by 2002:a05:6870:4308:b0:10b:8cbe:c945 with SMTP id w8-20020a056870430800b0010b8cbec945mr2176333oah.220.1656535417149; Wed, 29 Jun 2022 13:43:37 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "Zach O'Keefe" Date: Wed, 29 Jun 2022 13:43:01 -0700 Message-ID: Subject: Re: thp: enforcing constraints on file thps To: Yang Shi Cc: Song Liu , Matthew Wilcox , Miaohe Lin , Linux MM Content-Type: text/plain; charset="UTF-8" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1656535421; a=rsa-sha256; cv=none; b=m9Vd6zrQcg7iYkYes5q0muub8YQbVsZOp+yodp/uSBKxIhhgX+hVKSNrkHVtn9VAGJ0Ril g5KSTtJdEopfUiwZ/ckZNP1jR5TY4Ddurb0lrFFsK+ACGWQNs3J8ekQWzlDD7pc/0o0s5R kLZXjcTEfrbFLBsmaPU2jg5LWVOLdSM= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=hiOezGyL; spf=pass (imf14.hostedemail.com: domain of zokeefe@google.com designates 209.85.160.50 as permitted sender) smtp.mailfrom=zokeefe@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1656535421; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=unn1KvNAzE9h6f0ulBz87PP0Kg2idELqqTph3Y3vuSE=; b=YgohEn6r72d/T91LZFUCkk2qItnXELNzfj3Yb7OF7Lftal641CymJfXtyExSYn9vJTO9dq u3VyRvNidgRZyiPTW1XaiZZtjWiQGZLe9Jq2oXJj+fI0BZ2VFDb/G6UU9GRJzw3zMj22+J YH3YlOI32Ix+h1oh0Q2IEg+ghxkOxGo= X-Rspam-User: Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=hiOezGyL; spf=pass (imf14.hostedemail.com: domain of zokeefe@google.com designates 209.85.160.50 as permitted sender) smtp.mailfrom=zokeefe@google.com; dmarc=pass (policy=reject) header.from=google.com X-Rspamd-Server: rspam02 X-Stat-Signature: nbcn5c7wjjjggyewar6kkwegobjyyncw X-Rspamd-Queue-Id: 3D0D710001D X-HE-Tag: 1656535418-15862 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 Wed, Jun 29, 2022 at 10:26 AM Yang Shi wrote: > > On Wed, Jun 29, 2022 at 7:01 AM Zach O'Keefe wrote: > > > > Hey All, > > > > There are currently a number of paths where we can collapse file memory into > > THPs: > > > > 1a) khugepaged - target of vma being processed > > 1b) khugepaged - other vma found mapping file, able to lock mmap_lock in > > retract_page_tables() > > 1b) khugepaged - other vma found mapping file, deferred pte-mapped THP collapse, > > processed in collapse_pte_mapped_thp() > > 2) page fault finds hugepage in page cache + filemap_map_pages() > > > > In terms of system-enforced THP constraints: > > > > * vma flags + thps sysfs settings > > > > Checked in 1a. (1b now at least respects "never" THP mode after Yang Shi's > > cleanup series, but still doesn't respect "madvise" THP mode) > > > > * MMF_DISABLE_THP > > > > Checked in 1a and 1b > > > > I'm wondering if we should align these, and if so, in what direction? I would > > argue that a process marked MMF_DISABLE_THP, or a vma marked VM_NOHUGEPAGE, > > probably shouldn't be mapping at the pmd level, and that the appropriate checks > > should be added in those paths. > > That depends on how we explain the semantics of MMF_DISABLE_THP and > VM_NOHUGEPAGE IMHO. They definitely prevent from allocating/collapsing > new THPs for that process or vma, but shall they also prevent from > mapping existing THPs to PMD? Maybe not. Hey Yang, thanks for your thoughts. IIUC, you're basically saying things are working as intended? I see the argument that, if the THP is already assembled, we might as well just map it at the PMD level.. But as you mention, it weakens the API contract of MMF_DISABLE_THP and sysfs THP settings. I don't have any real world example where this is an issue, and am tempted to kick this down the road until someone has a good reason to change it - but at the same time - the exasperation incurred by all end users isn't guaranteed to reach linux-mm. Thanks, Zach > > > > Thanks, > > Zach