linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Shewmaker <agshew@gmail.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	alan@lxorguk.ukuu.org.uk, simon.jeons@gmail.com,
	ric.masonn@gmail.com
Subject: Re: [PATCH v8 3/3] mm: reinititalise user and admin reserves if memory is added or removed
Date: Mon, 8 Apr 2013 20:42:41 -0400	[thread overview]
Message-ID: <20130409004241.GA4277@localhost.localdomain> (raw)
In-Reply-To: <20130408133712.bd327017dec19a2c14e22662@linux-foundation.org>

On Mon, Apr 08, 2013 at 01:37:12PM -0700, Andrew Morton wrote:
> On Mon, 8 Apr 2013 15:07:38 -0400 Andrew Shewmaker <agshew@gmail.com> wrote:
> 
> > This patch alters the admin and user reserves of the previous patches 
> > in this series when memory is added or removed.
> > 
> > If memory is added and the reserves have been eliminated or increased above
> > the default max, then we'll trust the admin.
> > 
> > If memory is removed and there isn't enough free memory, then we
> > need to reset the reserves.
> > 
> > Otherwise keep the reserve set by the admin.
> > 
> > The reserve reset code is the same as the reserve initialization code.
> > 
> > Does this sound reasonable to other people? I figured that hot removal
> > with too large of memory in the reserves was the most important case 
> > to get right.
> 
> Seems reasonable to me.
> 
> I don't understand the magic numbers 1<<13 and 1<<17.  How could I? 
> Please add comments explaining how and why these were chosen.

The v9 patch I posted has this too, but here is a patch against 
yesterday's mmotm.

diff --git a/mm/mmap.c b/mm/mmap.c
index 099a16d..cee7e74 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -3119,6 +3119,13 @@ module_init(init_admin_reserve)
 /*
  * Reinititalise user and admin reserves if memory is added or removed.
  *
+ * The default user reserve max is 128MB, and the default max for the
+ * admin reserve is 8MB. These are usually, but not always, enough to
+ * enable recovery from a memory hogging process using login/sshd, a shell,
+ * and tools like top. It may make sense to increase or even disable the
+ * reserve depending on the existence of swap or variations in the recovery
+ * tools. So, the admin may have changed them.
+ *
  * If memory is added and the reserves have been eliminated or increased above
  * the default max, then we'll trust the admin.
  *
@@ -3134,10 +3141,16 @@ static int reserve_mem_notifier(struct notifier_block *nb,
 
 	switch (action) {
 	case MEM_ONLINE:
+		/*
+		 * Default max is 128MB. Leave alone if modified by operator.
+ 		 */
 		tmp = sysctl_user_reserve_kbytes;
 		if (0 < tmp && tmp < (1UL << 17))
 			init_user_reserve();
 
+		/*
+		 * Default max is 8MB. Leave alone if modified by operator.
+ 		 */
 		tmp = sysctl_admin_reserve_kbytes;
 		if (0 < tmp && tmp < (1UL << 13))
 			init_admin_reserve();

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  parent reply	other threads:[~2013-04-10 16:25 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-08 19:07 [PATCH v8 3/3] mm: reinititalise user and admin reserves if memory is added or removed Andrew Shewmaker
2013-04-08 20:37 ` Andrew Morton
2013-04-08 21:00   ` Andrew Shewmaker
2013-04-09 22:19     ` Andrew Morton
2013-04-09 23:56       ` Andrew Shewmaker
2013-04-10  0:05         ` Simon Jeons
2013-04-10  0:11           ` Andrew Shewmaker
2013-04-10  0:14             ` Simon Jeons
2013-04-10 15:56       ` Andrew Shewmaker
2013-04-09  0:42   ` Andrew Shewmaker [this message]
2013-04-08 20:57 ` Andrew Morton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130409004241.GA4277@localhost.localdomain \
    --to=agshew@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=ric.masonn@gmail.com \
    --cc=simon.jeons@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).