Question about admin_reserve_kbytes in GUESS mode

Question about admin_reserve_kbytes in GUESS mode

[Chunyu Hu]

[-- Attachment #1: Type: text/plain, Size: 873 bytes --]

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. 

....... 


-- 
Regards, 
Chunyu Hu 


[-- Attachment #2: Type: text/html, Size: 2353 bytes --]

Re: Question about admin_reserve_kbytes in GUESS mode

[Johannes Weiner]

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.

Re: Question about admin_reserve_kbytes in GUESS mode

[Chunyu Hu]

----- Original Message -----
> From: "Johannes Weiner" <hannes@cmpxchg.org>
> To: "Chunyu Hu" <chuhu@redhat.com>
> Cc: linux-mm@kvack.org, guro@fb.com, akpm@linux-foundation.org
> Sent: Tuesday, December 15, 2020 9:06:38 PM
> Subject: Re: Question about admin_reserve_kbytes in GUESS mode
> 
> 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?

Thanks for the reply!

We drafted a test according to the document. The step is something like:

In default GUESS overcommit memory mode:
Test#1:
total_memory=$(grep MemTotal /proc/meminfo | awk '{print $2}')
swapoff -a
echo ${total_memory} > /proc/sys/vm/admin_reserve_kbytes
useradd ark_test
su ark_test -c 'ls -al ~'  <------------------ We expect fail here, now it succeeds.


Test#2 (continue with Test#1)
sysctl -w vm.drop_caches=3
free_memory=$(grep MemFree /proc/meminfo | awk '{print $2}')
sysctl -w vm.admin_reserve_kbytes=$((free_memory-512*1024)) # Leave 512M memory
su ark_test -c 'memhog -r10 1g' <----------- consume 1G memory, we expect it fail, now it succeeds.


> 
> 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 thing described in document is useful, that we can config to leave some memory
to cap_sys_admin user.

> 
> 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.

I need sometime to understand what it means by 'in a row', you mean
parallel allocation that more than one threads do mmap() at same time?

-- 
Regards,
Chunyu Hu