Re: Question about admin_reserve_kbytes in GUESS mode

[Johannes Weiner <hannes@cmpxchg.org>]

On Tue, Dec 15, 2020 at 06:42:39AM -0500, Chunyu Hu wrote:
> Hello experts, 
> 
> I find admin_reserve_kbytes is not working as documented since 
> commit 8c7829b04c523cdc(mm: fix false-positive OVERCOMMIT_GUESS failures). 
> 
> Before that, available free pages are used to determine the allocation check, and admin_reserve_kbytes 
> was honored in the default GUESS over_commit mode. While after that commit, admin_reserve_kbytes 
> is not honored in default mode any more. This looks like break the sysctl usage?
> 
> Documentation/admin-guide/sysctl/vm.rst: 
> 
> admin_reserve_kbytes 
> ==================== 
> 
> The amount of free memory in the system that should be reserved for users 
> with the capability cap_sys_admin. 
> 
> admin_reserve_kbytes defaults to min(3% of free pages, 8MB) 
> 
> That should provide enough for the admin to log in and kill a process, 
> if necessary, under the default overcommit 'guess' mode.

Thanks for the report.

Can you elaborate on your usecase a bit? How you rely on the knob, and
how it's not working properly now?

It would be easy enough to this check back to the simplified formula,
I'm just having some trouble picturing how it would be useful.

The knob never (not since git, anyway) behaved the way it's documented
here. We don't track total virtual memory; instead the checks apply to
individual allocations. So it was never true that we reserve 3% of RAM
for admins. Rather, the biggest single mmap() request an admin could
do was 100% of RAM, whereas for unprivileged users it was 97% of RAM.
But you could always do two or more requests of that size in a row
anyway. It's not clear to me that this is a meaningful distinction.