Received-SPF: pass (google.com: domain of linux-kernel+bounces-198126-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Message-ID: <cce7a033-08ab-4d5e-967e-9b9493a2600e@linux.alibaba.com>
Date: Sun, 2 Jun 2024 12:15:40 +0800
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 0/6] add mTHP support for anonymous shmem
To: David Hildenbrand <david@redhat.com>, akpm@linux-foundation.org,
 hughd@google.com
Cc: willy@infradead.org, wangkefeng.wang@huawei.com, ying.huang@intel.com,
 21cnbao@gmail.com, ryan.roberts@arm.com, shy828301@gmail.com,
 ziy@nvidia.com, ioworker0@gmail.com, da.gomez@samsung.com,
 p.raghav@samsung.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org
References: <cover.1717033868.git.baolin.wang@linux.alibaba.com>
 <f1783ff0-65bd-4b2b-8952-52b6822a0835@redhat.com>
 <db3517d0-54b1-4d3a-b798-1c13572d07be@linux.alibaba.com>
 <502fb3df-b42b-4f0c-a98d-348c3d544721@redhat.com>
From: Baolin Wang <baolin.wang@linux.alibaba.com>
In-Reply-To: <502fb3df-b42b-4f0c-a98d-348c3d544721@redhat.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit


On 2024/5/31 19:13, David Hildenbrand wrote:
>>>
>>> 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.

OK.

>>>
>>> "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."

Sure. Thanks.