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: <cab761ce-14f6-4105-817c-c7cf6ffac0a7@linux.alibaba.com>
Date: Mon, 1 Jul 2024 15:18:09 +0800
From: Baolin Wang <baolin.wang@...ux.alibaba.com>
To: David Hildenbrand <david@...hat.com>, Bang Li <libang.li@...group.com>,
 hughd@...gle.com, akpm@...ux-foundation.org
Cc: ryan.roberts@....com, wangkefeng.wang@...wei.com, ziy@...dia.com,
 linux-kernel@...r.kernel.org, linux-mm@...ck.org,
 Barry Song <21cnbao@...il.com>
Subject: Re: [PATCH] support "THPeligible" semantics for mTHP with anonymous
 shmem



On 2024/7/1 14:55, David Hildenbrand wrote:
> On 01.07.24 08:47, Baolin Wang wrote:
>> CC Barry.
>>
>> On 2024/6/28 18:49, Bang Li wrote:
>>> After the commit 7fb1b252afb5 ("mm: shmem: add mTHP support for
>>> anonymous shmem"), we can configure different policies through
>>> the multi-size THP sysfs interface for anonymous shmem. But
>>> currently "THPeligible" indicates only whether the mapping is
>>> eligible for allocating THP-pages as well as the THP is PMD
>>> mappable or not for anonymous shmem, we need to support semantics
>>> for mTHP with anonymous shmem similar to those for mTHP with
>>> anonymous memory.
>>
>> I did not see a consensus that "THP*" related statistics should contain
>> mTHP in previous discussion [1].
>>
>> In addition, if we all agree that "THPeligible" should include mTHP
>> statistics, you should update the corresponding documentation to keep
>> consistency.
>>
>> [1]
>> https://lore.kernel.org/linux-mm/202406262300.iAURISyJ-lkp@intel.com/T/#md7a77056110cebcc2a9b3cd7e4a8d682667f6ba5
>>
> 
> Fortunately, documentation (Documentation/filesystems/proc.rst) says:
> 
> "THPeligible" indicates whether the mapping is eligible for allocating 
> naturally aligned THP pages of any currently enabled size. 1 if true, 0 
> otherwise."
> 
> So that documentation is already pretty clear (we just have to make sure 
> the other ones are properly documented, for example as raised in reply 
> to [1]).

OK, great. Thanks.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ