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]
Date: Mon, 1 Jul 2024 08:55:20 +0200
From: David Hildenbrand <david@...hat.com>
To: Baolin Wang <baolin.wang@...ux.alibaba.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 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]).

-- 
Cheers,

David / dhildenb


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ