linux-kernel - Re: [PATCH v3 0/6] add mTHP support for anonymous shmem

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <502fb3df-b42b-4f0c-a98d-348c3d544721@redhat.com>
Date: Fri, 31 May 2024 13:13:48 +0200
From: David Hildenbrand <david@...hat.com>
To: Baolin Wang <baolin.wang@...ux.alibaba.com>, akpm@...ux-foundation.org,
 hughd@...gle.com
Cc: willy@...radead.org, wangkefeng.wang@...wei.com, ying.huang@...el.com,
 21cnbao@...il.com, ryan.roberts@....com, shy828301@...il.com,
 ziy@...dia.com, ioworker0@...il.com, da.gomez@...sung.com,
 p.raghav@...sung.com, linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 0/6] add mTHP support for anonymous shmem

>>
>> As a default, we should not be using large folios / mTHP for any shmem,
>> just like we did with THP via shmem_enabled. This is what this series
>> currently does, and is aprt of the whole mTHP user-space interface design.
>>
>> Further, the mTHP controls should control all of shmem, not only
>> "anonymous shmem".
> 
> Yes, that's what I thought and in my TODO list.

Good, it would be helpful to coordinate with Daniel and Pankaj.

> 
>>
>> Also, we should properly fallback within the configured sizes, and not
>> jump "over" configured sizes. Unless there is a good reason.
>>
>> (3) khugepaged
>>
>> khugepaged needs to handle larger folios properly as well. Until fixed,
>> using smaller THP sizes as fallback might prohibit collapsing a
>> PMD-sized THP later. But really, khugepaged needs to be fixed to handle
>> that. >
>> (4) force/disable
>>
>> These settings are rather testing artifacts from the old ages. We should
>> not add them to the per-size toggles. We might "inherit" it from the
>> global one, though.
> 
> Sorry, I missed this. So I thould remove the 'force' and 'deny' option
> for each mTHP, right?

Yes, that's my understanding. But we have to keep them on the top level 
for any possible user out there.

> 
>>
>> "within_size" might have value, and especially for consistency, we
>> should have them per size.
>>
>>
>>
>> So, this series only tackles anonymous shmem, which is a good starting
>> point. Ideally, we'd get support for other shmem (especially during
>> fault time) soon afterwards, because we won't be adding separate toggles
>> for that from the interface POV, and having inconsistent behavior
>> between kernel versions would be a bit unfortunate.
>>
>>
>> @Baolin, this series likely does not consider (4) yet. And I suggest we
>> have to take a lot of the "anonymous thp" terminology out of this
>> series, especially when it comes to documentation.
> 
> Sure. I will remove the "anonymous thp" terminology from the
> documentation, but want to still keep it in the commit message, cause I
> want to start from the anonymous shmem.

For commit message and friends makes sense. The story should be 
"controls all of shmem/tmpfs, but support will be added iteratively. The 
first step is anonymous shmem."

-- 
Cheers,

David / dhildenb