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: <13bfe4a4-193d-4e8e-a520-7e261b9d6131@linux.alibaba.com>
Date: Sat, 16 Nov 2024 11:00:14 +0800
From: Baolin Wang <baolin.wang@...ux.alibaba.com>
To: David Hildenbrand <david@...hat.com>, Daniel Gomez
 <da.gomez@...sung.com>, akpm@...ux-foundation.org, hughd@...gle.com
Cc: willy@...radead.org, wangkefeng.wang@...wei.com, 21cnbao@...il.com,
 ryan.roberts@....com, ioworker0@...il.com, linux-mm@...ck.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 4/5] mm: shmem: add a kernel command line to change the
 default huge policy for tmpfs



On 2024/11/15 22:54, David Hildenbrand wrote:
> On 15.11.24 15:02, Daniel Gomez wrote:
>> On Tue Nov 12, 2024 at 8:45 AM CET, Baolin Wang wrote:
>>> Now the tmpfs can allow to allocate any sized large folios, and the 
>>> default
>>> huge policy is still 'never'. Thus adding a new command line to change
>>> the default huge policy will be helpful to use the large folios for 
>>> tmpfs,
>>> which is similar to the 'transparent_hugepage_shmem' cmdline for shmem.
>>
>>
>> I think it would be good to include a summary of why tmpfs is not
>> enabling large folios by default as the other fs. David has been
>> pretty good at repeating the reasons over and over and it would be very
>> valuable to have them included here.


OK. I'd like to directly quote David's previous comments. So hope Andew 
can help include the updated commit message:

=====
Now the tmpfs can allow to allocate any sized large folios, and the 
default huge policy is still prefered to be 'never'. Due to tmpfs not 
behaving like other file systems in some cases as previously explained 
by David[1]:

"
I think I raised this in the past, but tmpfs/shmem is just like any
other file system .. except it sometimes really isn't and behaves much
more like (swappable) anonymous memory. (or mlocked files)

There are many systems out there that run without swap enabled, or with
extremely minimal swap (IIRC until recently kubernetes was completely
incompatible with swapping). Swap can even be disabled today for shmem
using a mount option.

That's a big difference to all other file systems where you are
guaranteed to have backend storage where you can simply evict under
memory pressure (might temporarily fail, of course).

I *think* that's the reason why we have the "huge=" parameter that also
controls the THP allocations during page faults (IOW possible memory
over-allocation). Maybe also because it was a new feature, and we only
had a single THP size.
"

Thus adding a new command line to change the default huge policy will be 
helpful to use the large folios for tmpfs, which is similar to the 
'transparent_hugepage_shmem' cmdline for shmem.

[1] 
https://lore.kernel.org/all/cbadd5fe-69d5-4c21-8eb8-3344ed36c721@redhat.com/

> Yes. We also discussed in v4 the idea of having a Kconfig option to just 
> change the default policy to "always". We could mention that here as well.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ