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  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Date:   Thu, 24 Dec 2020 12:13:27 +0100
From:   Oleksandr Natalenko <oleksandr@...alenko.name>
To:     linux-kernel@...r.kernel.org
Cc:     Mandeep Singh Baines <mandeep.baines@...il.com>,
        Guenter Roeck <groeck@...omium.org>,
        Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org
Subject: min_filelist_kbytes vs file_is_tiny

Hello, Mandeep, Guenter et al.

I came across the out-of-tree patch [1] that apparently is still alive
after 10 years of residing in the Chromium OS tree, and I have a couple
of questions if you don't mind spending your time answering them.

1. is this knob really necessary given there's an explicit bailout
mechanism relying on `file_is_tiny` which depends on the sum of high
watermarks across the zones? Wouldn't increasing `vm.min_free_kbytes`
achieve basically the same?

2. if `vm.min_free_kbytes` is not an option, would setting
`file_is_tiny` based on your `min_filelist_kbytes` knob achieve the
same?

3. if not, is `memory.min` cgroup2 knob supposed to work in a similar
manner? it looks to be unavailable for the root cgroup, though.

What I'm looking for, basically, is to achieve the effect of the
mentioned patch using mechanisms that are already available in the
upstream kernel.

Thank you.

[1] https://chromium.googlesource.com/chromiumos/third_party/kernel-next/+/545e2917dbd863760a51379de8c26631e667c563^!/

-- 
  Oleksandr Natalenko (post-factum)

Powered by blists - more mailing lists