Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) client-ip=23.128.96.37;
Received-SPF: Pass (protection.outlook.com: domain of nvidia.com designates
 216.228.117.161 as permitted sender) receiver=protection.outlook.com;
 client-ip=216.228.117.161; helo=mail.nvidia.com; pr=C
Message-ID: <b2d19306-0d68-4aef-9b68-15948ddc8ea0@nvidia.com>
Date:   Mon, 27 Nov 2023 18:09:47 -0800
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [RESEND PATCH v7 00/10] Small-sized THP for anonymous memory
Content-Language: en-US
To:     Ryan Roberts <ryan.roberts@arm.com>,
        Alistair Popple <apopple@nvidia.com>,
        David Hildenbrand <david@redhat.com>
CC:     Matthew Wilcox <willy@infradead.org>,
        Andrew Morton <akpm@linux-foundation.org>,
        Yin Fengwei <fengwei.yin@intel.com>,
        Yu Zhao <yuzhao@google.com>,
        Catalin Marinas <catalin.marinas@arm.com>,
        "Anshuman Khandual" <anshuman.khandual@arm.com>,
        Yang Shi <shy828301@gmail.com>,
        "Huang, Ying" <ying.huang@intel.com>, Zi Yan <ziy@nvidia.com>,
        Luis Chamberlain <mcgrof@kernel.org>,
        Itaru Kitayama <itaru.kitayama@gmail.com>,
        "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
        David Rientjes <rientjes@google.com>,
        Vlastimil Babka <vbabka@suse.cz>,
        Hugh Dickins <hughd@google.com>,
        Kefeng Wang <wangkefeng.wang@huawei.com>, <linux-mm@kvack.org>,
        <linux-arm-kernel@lists.infradead.org>,
        <linux-kernel@vger.kernel.org>
References: <20231122162950.3854897-1-ryan.roberts@arm.com>
 <ZV9267tQEhoPzCru@casper.infradead.org>
 <f8e518f2-fb15-4295-a335-bea5a8010ab2@arm.com>
 <ZWC9lwDAjMZsNzoG@casper.infradead.org>
 <9c8f6d2a-7ed8-45d2-9684-d77489bd99b8@redhat.com>
 <ZWDG6BYqmZVpyTLL@casper.infradead.org>
 <26c361bc-6d87-4a57-9fae-ef635c9039c7@redhat.com>
 <87sf4rppuc.fsf@nvdebian.thelocal>
 <51e6c9f1-e863-464b-b5f3-d7f60a7ebed6@arm.com>
From:   John Hubbard <jhubbard@nvidia.com>
In-Reply-To: <51e6c9f1-e863-464b-b5f3-d7f60a7ebed6@arm.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Nov 2023 02:10:02.7479
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 9b26f015-e33c-4c46-1829-08dbefb721e1
X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=43083d15-7273-40c1-b7db-39efd9ccc17a;Ip=[216.228.117.161];Helo=[mail.nvidia.com]
X-MS-Exchange-CrossTenant-AuthSource: MN1PEPF0000F0E4.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL1PR12MB5221
X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FORGED_SPF_HELO,
        RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_NONE,
        T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (snail.vger.email [0.0.0.0]); Mon, 27 Nov 2023 18:11:48 -0800 (PST)

On 11/27/23 02:31, Ryan Roberts wrote:
> On 27/11/2023 08:20, Alistair Popple wrote:
>> David Hildenbrand <david@redhat.com> writes:
>>> On 24.11.23 16:53, Matthew Wilcox wrote:
>>>> On Fri, Nov 24, 2023 at 04:25:38PM +0100, David Hildenbrand wrote:
>>>>> On 24.11.23 16:13, Matthew Wilcox wrote:
>>>>>> On Fri, Nov 24, 2023 at 09:56:37AM +0000, Ryan Roberts wrote:
>>>>>>> On 23/11/2023 15:59, Matthew Wilcox wrote:
>>>>>>>> On Wed, Nov 22, 2023 at 04:29:40PM +0000, Ryan Roberts wrote:
...
>>> Maybe that's the reason why FreeBSD calls them "medium-sized
>>> superpages", because "Medium-sized" seems to be more appropriate to
>>> express something "in between".
>>
>> Transparent Medium Pages?

I enjoyed this suggestion, because the resulting acronym is TMP. Which
*might* occasionally lead to confusion. haha :)

> 
> I don't think this is future proof; If we are going to invent a new term, it
> needs to be indpendent of size to include all sizes including PMD-size and
> perhaps in future, bigger-than-PMD-size. I think generalizing the meaning of
> "huge" in THP to mean "bigger than the base page" is the best way to do this.
> Then as David says, over time people will qualify it with a specific size when
> appropriate.
> 
>>
>>> So far I thought the reason was because they focused on 64k only.
>>>
>>> Never trust a German guy on naming suggestions. John has so far been
>>> my naming expert, so I'm hoping he can help.
>>
>> Likewise :-)
>>

I appreciate the call-out, although my latest suggestion seems to have
gotten buried in the avalanche of discussions. I'm going to revive it and
try again, though.

>>> "Sub-pmd-sized THP" is just mouthful. But then, again, this is would
>>> just be a temporary name, and in the future THP will just naturally
>>> come in multiple sizes (and others here seem to agree on that).
> 
> I actually don't mind "sub-pmd-sized THP" given the few locations its actually
> going to live.
> 
>>>
>>>
>>> But just to repeat: I don't think there is need to come up with new
>>> terminology and that there will be mass-confusion. So far I've not
>>> heard a compelling argument besides "one memory counter could confuse
>>> an admin that explicitly enables that new behavior.".
>>>
>>> Side note: I'm, happy that we've reached a stage where we're
>>> nitpicking on names :)
>>
> 
> Agreed. We are bikeshedding here. But if we really can't swallow "small-sized
> THP" then perhaps the most efficient way to move this forwards is to review the
> documentation (where "small-sized THP" appears twice in order to differentiate
> from PMD-sized THP) - its in patch 3. Perhaps it will be easier to come up with
> a good description in the context of those prose? Then once we have that,
> hopefully a term will fall out that I'll update the commit logs with.
> 

I will see you over in patch 3, then. I've already looked at it and am going
to suggest a long and a short name. The long name is for use in comments and
documentation, and the short name is for variable fragments:

     Long name:  "pte-mapped THPs"
     Short names: pte_thp, or pte-thp


thanks,
-- 
John Hubbard
NVIDIA