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>
WARNING: multiple messages have this Message-ID (diff)
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();
next prev parent reply other threads:[~2013-04-10 16:25 UTC|newest]
Thread overview: 22+ 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 19:07 ` Andrew Shewmaker
2013-04-08 20:37 ` Andrew Morton
2013-04-08 20:37 ` Andrew Morton
2013-04-08 21:00 ` Andrew Shewmaker
2013-04-08 21:00 ` Andrew Shewmaker
2013-04-09 22:19 ` Andrew Morton
2013-04-09 22:19 ` Andrew Morton
2013-04-09 23:56 ` Andrew Shewmaker
2013-04-09 23:56 ` Andrew Shewmaker
2013-04-10 0:05 ` Simon Jeons
2013-04-10 0:05 ` Simon Jeons
2013-04-10 0:11 ` Andrew Shewmaker
2013-04-10 0:11 ` Andrew Shewmaker
2013-04-10 0:14 ` Simon Jeons
2013-04-10 0:14 ` Simon Jeons
2013-04-10 15:56 ` Andrew Shewmaker
2013-04-10 15:56 ` Andrew Shewmaker
2013-04-09 0:42 ` Andrew Shewmaker [this message]
2013-04-09 0:42 ` Andrew Shewmaker
2013-04-08 20:57 ` Andrew Morton
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.