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 15509CDB482 for ; Fri, 13 Oct 2023 07:46:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AAF218D015D; Fri, 13 Oct 2023 03:46:51 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A5F118D0015; Fri, 13 Oct 2023 03:46:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9274E8D015D; Fri, 13 Oct 2023 03:46:51 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 84A368D0015 for ; Fri, 13 Oct 2023 03:46:51 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 57A03B4A86 for ; Fri, 13 Oct 2023 07:46:51 +0000 (UTC) X-FDA: 81339656622.08.9631CD1 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf17.hostedemail.com (Postfix) with ESMTP id 0BBEB4000F for ; Fri, 13 Oct 2023 07:46:48 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=CDKYHO+D; spf=pass (imf17.hostedemail.com: domain of david@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1697183209; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=TphMvB1CPmRLPW6U1J+q+vD0ldjgA4gT+OdpEDDv6mM=; b=hGxpkcXHKDbAUazQOWyGj+11KlTAQE53zlJIU9vfRw+6srPLpT+Vy7F2N0EVZRXIZb7ZNm 1PC/DLBF+YLQF5AQsc2GK1Lgv08auCV5GIF6A/d7+jMDwCE2MwI2zSHnR6d5IWQAv/eRiI GcDl/FvJcZdPA4h6Z1inQTKh4UotdEI= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1697183209; a=rsa-sha256; cv=none; b=F3CB/bWKKK4mQvtF/lenm76n9NMOulZU6jXOFyxTGEoqSeTC6OWEEayleEmjocQJepbjN6 JyNt9TUVLdk8Avd12Z7sn9IwHzJa3AqZzXqa8X7h5uxXD+eyJjaM6P+m7+x0x0ozWXQM31 FTBkExh8uGZ1nxphHSLIKm6rua/zI64= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=CDKYHO+D; spf=pass (imf17.hostedemail.com: domain of david@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1697183208; h=from:from: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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=TphMvB1CPmRLPW6U1J+q+vD0ldjgA4gT+OdpEDDv6mM=; b=CDKYHO+DMebhB7WtzX+/+uwcQ5OQTl9ANx/ezVP1RVX5Lx4FLgC0xm9EK9GEejfroHwFFc uLLs1NFjBQg0E4aUxYJlpVlFW4u51VvgmRmQTFwPoNLQ56bu67TSQQyOC/cmiTK4RHhTcR XfDf0/FHg4arME/mGSyQs1Pate7jzi4= Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-261-lgvxRpEbMrOrTtmRLL2A9w-1; Fri, 13 Oct 2023 03:46:46 -0400 X-MC-Unique: lgvxRpEbMrOrTtmRLL2A9w-1 Received: by mail-wr1-f72.google.com with SMTP id ffacd0b85a97d-31fd48da316so1064199f8f.3 for ; Fri, 13 Oct 2023 00:46:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1697183206; x=1697788006; h=content-transfer-encoding:in-reply-to:organization:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=TphMvB1CPmRLPW6U1J+q+vD0ldjgA4gT+OdpEDDv6mM=; b=iFXFFsjslAG3Iia+w+hbxTDmUjDQzS580e+5h5XgrwfkmqJVFyvz9Pfr1O9OJdlZj0 zYHOYB3mTVIzuVlTGys59/F5+/ntYRmN+v0lFz2FI7IeHk02q0Qt1x0X6atVeisbUllf EZL7+pBYpdd8oPzZm51o2okCpsni+rlg+pypFBFsUrjXDkjj+LxQHyZJz0VMl4c9euug cxIMTzUFjFPGzfeyV1V+Rebx9GdkTu1i4rMz8GeIauFtCbJpWinu/ND+CdPLES9ix+rg ytLenTaESqcEWjduk8ounuEP8GIA40k45ywheuOfu3CjootsPDqWBWq0jd0IBbkbNrfK gu8g== X-Gm-Message-State: AOJu0YxRdHC0NB4y+YoJaQ37N/YObP5ES68jxKurlXAdbjVW1DV1a4QU EiPn4oDPb70DYbXssxuhR+dxYb1RQRXY20xpeT7aNGtfoX5rxSlm5PwEc66xJlrO/G7nS7x6eOy P8bjALS1gKDY= X-Received: by 2002:a05:6000:1246:b0:317:6513:da7e with SMTP id j6-20020a056000124600b003176513da7emr21308672wrx.36.1697183205650; Fri, 13 Oct 2023 00:46:45 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFSSrs6m9cH6/GO/dAxAJtE+wFDvIs0eYPELm+NBLR10v6qYJ4xX620jSepqwwuna9L3vW1Uw== X-Received: by 2002:a05:6000:1246:b0:317:6513:da7e with SMTP id j6-20020a056000124600b003176513da7emr21308657wrx.36.1697183205174; Fri, 13 Oct 2023 00:46:45 -0700 (PDT) Received: from ?IPV6:2003:cb:c718:9300:1381:43e2:7c78:b68f? (p200300cbc7189300138143e27c78b68f.dip0.t-ipconnect.de. [2003:cb:c718:9300:1381:43e2:7c78:b68f]) by smtp.gmail.com with ESMTPSA id m12-20020a056000024c00b0032d88e370basm6036223wrz.34.2023.10.13.00.46.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 13 Oct 2023 00:46:44 -0700 (PDT) Message-ID: <82c16241-6c9f-88b7-5644-3a397f842e9e@redhat.com> Date: Fri, 13 Oct 2023 09:46:43 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.15.1 Subject: Re: [PATCH v1 0/5] mm, kpageflags: support folio and fix output for compound pages To: Naoya Horiguchi Cc: linux-mm@kvack.org, Andrew Morton , Matthew Wilcox , "Kirill A. Shutemov" , Mike Kravetz , Miaohe Lin , Vlastimil Babka , Muchun Song , Naoya Horiguchi , linux-kernel@vger.kernel.org, Ryan Roberts References: <20231010142801.3780917-1-naoya.horiguchi@linux.dev> <63d119f7-5adb-861a-00c2-69a92b19ef9b@redhat.com> <20231012150226.GA473412@u2004> <86170ebf-cbe3-1cda-dcb4-87e18695f9cd@redhat.com> <20231013005457.GA712115@ik1-406-35019.vs.sakura.ne.jp> From: David Hildenbrand Organization: Red Hat In-Reply-To: <20231013005457.GA712115@ik1-406-35019.vs.sakura.ne.jp> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 0BBEB4000F X-Rspam-User: X-Stat-Signature: ehcxkgak5bow1zknoqpxu118hdw5qsne X-Rspamd-Server: rspam03 X-HE-Tag: 1697183208-207826 X-HE-Meta: U2FsdGVkX18MuvNVaHdK2F/PcSlTSfbLoZIjmnQ8e1ZEEw3JzEes9H7+E0pLNuod0yjY4bnefdQOVnkSqme8GpJzRPtRNb6pfR7iUmnyICSw3pX8KH4/+kkqlU4LLln0r21sT/Pnap8oc+Nf4IKtcdN/ObYj0goBErqyfS8QHQoj37B4ejMtGtgSObidr3mWHDd7NFaldwyRZeiDHBvtjjCkHCaFSXKZFU0PuqtREBA35JcBKXXSrjJiCSoIXIE61yXz1Lg5tXrd1XwpOa5UGMRfqsGHSpQWXbgOoTGa7XmPy0jCkq6/CMghEBbogO2wfXSVinYSCvvmSD9Hma6M2UBRySjiBSB1RHiUjZZn4CZN9ywqnRudx8gdTDgzFsf1ds7+OgrDhrLY4ZmYn5PoRyzUfZf918GQ1XpiTML2aIjuEO4HygfDWTAJnFhjwS5FIXBTgAzfFDtKWx31Cyvs7eK3rEUih29WoalW9rICa4vzBNgk9Pfb/QdvlU5gd+NVW4mbZ3pvRV2gsexsHbr0f0CGlG0bdk5+O8XcyIgymhgMT8v8n2k9bz7SdaH5vQzpANzOQ++GO/ltu2ec/W2fugtyMAzn7KwJ3LPkcP1LFsYT/YuTuawdfZmll06RhZFuQJDYjojhMNkE8hT9TycwirHtj1jtGW4qOCd8FcetV1l9KlKPK+tVESlfa0d2tJ3THeA7E1Eaj4JIODT5a5e5rEyPo6exJhgPGNof6KeNxcE/LYdTDdHvB+5+Lk52Q+zcF9LsNx+h8DUtMix3nJDxLrM4YTXryvCTSioaYeVFys09xtN6X98LmYEom8aGg3RyBnS9wMxReoNex7ftdPTBRh4e0Lw1t5f8ShNnNfIUENnbqrp6vHe1+b6hwi+1lBLG/ZsWvmvataFnVkMA1fD07cMTMECiaL4cc0b4Rbg67UOSFvrGvxoeXjGE2mp9QTcgnwvMT6P6WtlnSfmMzsL 5Pa1LxtI zCjl8Y9hK0a0RMuCbf6FlL+ktjKBzb6mNZEdRNP/6dX1atOjKm+rEWkbxbK9EZIUXQOr6BVtdTAdSEOcW05rGDxMycI7Nt6KqAGeXgl4X5nO4EkJnfUCv931W/ZfNgItCo7iTVs4EXZisB8FVDRHp7mClp9I00UBwvCqPD0RnjFFqmK9p0ej0ek/0rmKhoxH+Cm99Qi3gd8mwKXmY5nPcPZRZN1U/rdpXp4TbzGVjYc7b+aBwRSULEC27w9RP7WmMGl3acfbQBig3K5l3uYSTDYqL3VwJK/3g4Lk+xH3Nwzmda8K8v2V6ppkV54G2iSN95BZssCY3fBGGvnB79QnwyH3wbpJ3Z8EEdoGYgLplbhDQvIUBBBgQsHMI8+n5SVL0HF2N 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 13.10.23 02:54, Naoya Horiguchi wrote: > On Thu, Oct 12, 2023 at 05:30:34PM +0200, David Hildenbrand wrote: >> On 12.10.23 17:02, Naoya Horiguchi wrote: >>> On Thu, Oct 12, 2023 at 10:33:04AM +0200, David Hildenbrand wrote: >>>> On 10.10.23 16:27, Naoya Horiguchi wrote: >>>>> Hi everyone, >>>>> >>>>> This patchset addresses 2 issues in /proc/kpageflags. >>>>> >>>>> 1. We can't easily tell folio from thp, because currently both pages are >>>>> judged as thp, and >>>>> 2. we see some garbage data in records of compound tail pages because >>>>> we use tail pages to store some internal data. >>>>> >>>>> These issues require userspace programs to do additional work to understand >>>>> the page status, which makes situation more complicated. >>>>> >>>>> This patchset tries to solve these by defining KPF_FOLIO for issue 1., and >>>>> by hiding part of page flag info on tail pages of compound pages for issue 2. >>>>> >>>>> I think that technically some compound pages like thp/hugetlb/slab could be >>>>> considered as folio, but in this version KPF_FOLIO is set only on folios >>>> >>>> At least thp+hugetlb are most certainly folios. Regarding slab, I suspect we >>>> no longer call them folios (cannot be mapped to user space). But Im not sure >>>> about the type hierarchy. >>> >>> I'm not sure about the exact definition of "folio", and I think it's better >>> to make KPF_FOLIO set based on the definition. >> >> Me neither. But in any case a THP *is* a folio. So you'd have to set that >> flag in any case. > > OK. > >> >> And any order-0 page (i.e., anon, pagecache) is also a folio. What you seem >> to imply with folio is "large folio". So KPF_FOLIO is really wrong as far as >> I can tell. > > Ah, I meant "large folio" for the new flag, so it might have been better to > name it KPF_LARGE_FOLIO. > >> >>> "being mapped to userspace" can be one possible criteria for the definition. >>> But reading source code, folio_slab() and slab_folio() convert between >>> struct slab and struct folio, so I feel that someone might think a slab is >>> a kind of folio. >> >> I keep forgetting if "folio" is just the generic term for any order-0 or >> compound page, or only for some of them. I usually live in the "anon" world, >> so I don't get reminded that often :) > > I didn't notice that an order-0 page is also a folio. > >> >> >>>>> in pagecache (so "folios in narrower meaning"). I'm not confident about >>>>> this choice, so if you have any idea about this, please let me know. >>>> >>>> It does sound inconsistent. What exactly do you want to tell user space with >>>> the new flag? >>> >>> The current most problematic behavior is to report folio as thp (order-2 >>> pagecache page is definitely a folio but not a thp), and this is what the >>> new flag is intended to tell. >> >> We are currently considering calling these sub-PMD sized THPs "small-sized >> THP". [1] Arguably, we're starting with the anon part where we won't get >> around exposing them to the user in sysfs. >> >> So I wouldn't immediately say that these things are not THPs. They are not >> PMD-sized THP. A slab/hugetlb is certainly not a thp but a folio. Whereby >> slabs can also be order-0 folios, but hugetlb can't. >> >> >> Looking at other interfaces, we do expose: >> >> include/uapi/linux/kernel-page-flags.h:#define KPF_COMPOUND_HEAD 15 >> include/uapi/linux/kernel-page-flags.h:#define KPF_COMPOUND_TAIL 16 >> >> So maybe we should just continue talking about compound pages or do we have >> to use both terms here in this interface? > > Extending the concept of thp to arbitrary size of thp sounds good to me. > If patchset [1] will be merged, then setting KPF_THP on large folios is totally > fine and one of my problem in this patchset will be automatically resolved. CCing Ryan. > So I'm thinking of not adding new flag and just focusing on garbage data issue. That sounds minimal and reasonable! Flags/values that logically belong to the head (although are stored in the tail) should probably be exposed along with the head. Flags that apply to the actual tail pages should stay with the tail pages. > > Thank you very much for sharing ideas. Thank you! -- Cheers, David / dhildenb