PATCH: Root reservations for strict overcommit

PATCH: Root reservations for strict overcommit

[Alan Cox]

This was on my TODO list for a while and it turns out someone already fixed the
armwaving overcommit mode for the same problem. It is easy to get into a
situation where you have no overcommit and nothing can be done because there is
no memory to clean up the stable but non-useful state of the machine.

The fix is trivial and duplicated from the armwaving overcommit code path.
The last 3% of the memory can be claimed by root processes only. It isn't a
cure but it does seem to solve the real world problems - at least providing
you have enough memory for 3% to be useful 8).

--- security/commoncap.c~	2004-08-31 15:27:46.777504736 +0100
+++ security/commoncap.c	2004-08-31 15:27:46.778504584 +0100
@@ -357,6 +357,11 @@
 
 	allowed = (totalram_pages - hugetlb_total_pages())
 	       	* sysctl_overcommit_ratio / 100;
+	/*
+	 * Leave the last 3% for root
+	 */
+	if (!capable(CAP_SYS_ADMIN))
+		allowed -= allowed / 32;
 	allowed += total_swap_pages;
 
 	if (atomic_read(&vm_committed_space) < allowed)

Re: PATCH: Root reservations for strict overcommit

[Alan Cox]

On Maw, 2004-08-31 at 18:13, Bill Davidsen wrote:
> Would it be a problem to put a lower bound on how much to leave for 
> root? If it's really too small to be useful, perhaps one of (a) reserve 
> enough to be useful or (b) don't bother to reserve at all, should be 

Possibly. I'm currently following what someone appears to have decided
is correct behaviour. It probably should be tunable

Re: PATCH: Root reservations for strict overcommit

[Bill Davidsen]

Alan Cox wrote:
> This was on my TODO list for a while and it turns out someone already fixed the
> armwaving overcommit mode for the same problem. It is easy to get into a
> situation where you have no overcommit and nothing can be done because there is
> no memory to clean up the stable but non-useful state of the machine.
> 
> The fix is trivial and duplicated from the armwaving overcommit code path.
> The last 3% of the memory can be claimed by root processes only. It isn't a
> cure but it does seem to solve the real world problems - at least providing
> you have enough memory for 3% to be useful 8).
> 
> --- security/commoncap.c~	2004-08-31 15:27:46.777504736 +0100
> +++ security/commoncap.c	2004-08-31 15:27:46.778504584 +0100
> @@ -357,6 +357,11 @@
>  
>  	allowed = (totalram_pages - hugetlb_total_pages())
>  	       	* sysctl_overcommit_ratio / 100;
> +	/*
> +	 * Leave the last 3% for root
> +	 */
> +	if (!capable(CAP_SYS_ADMIN))
> +		allowed -= allowed / 32;
>  	allowed += total_swap_pages;
>  
>  	if (atomic_read(&vm_committed_space) < allowed)

Would it be a problem to put a lower bound on how much to leave for 
root? If it's really too small to be useful, perhaps one of (a) reserve 
enough to be useful or (b) don't bother to reserve at all, should be 
selected.

I don't know what you have in mind for "useful," but it seems likely 
that a really small machine would be better off giving up any memory 
unless it was useful.


-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

Re: PATCH: Root reservations for strict overcommit

[V13]

On Tuesday 31 August 2004 19:37, Alan Cox wrote:
> On Maw, 2004-08-31 at 18:13, Bill Davidsen wrote:
> > Would it be a problem to put a lower bound on how much to leave for
> > root? If it's really too small to be useful, perhaps one of (a) reserve
> > enough to be useful or (b) don't bother to reserve at all, should be
>
> Possibly. I'm currently following what someone appears to have decided
> is correct behaviour. It probably should be tunable

I believe it makes more sense to describe it as KB instead of %. Noone should 
have to reserve 120MB for root on a 4G box. Even if it is tunable, memory 
size seems better than percent since you'll not have to change it when you 
add/remove memory from your box.

<<V13>>

Re: PATCH: Root reservations for strict overcommit

[Paul Jackson]

> Noone should have to reserve 120MB for root on a 4G box. 

Much less 120GB on a 4T box ;)

-- 
                          I won't rest till it's the best ...
                          Programmer, Linux Scalability
                          Paul Jackson <pj@sgi.com> 1.650.933.1373