Re: Question about admin_reserve_kbytes in GUESS mode

[Chunyu Hu <chuhu@redhat.com>]

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