From: Andrew Morton <akpm@linux-foundation.org>
To: Andrew Shewmaker <agshew@gmail.com>
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 v5 1/2] mm: limit growth of 3% hardcoded other user reserve
Date: Tue, 12 Mar 2013 16:01:36 -0700 [thread overview]
Message-ID: <20130312160136.b0f09ca7b1b4f2efe01f6617@linux-foundation.org> (raw)
In-Reply-To: <20130306235201.GA1421@localhost.localdomain>
On Wed, 6 Mar 2013 18:52:01 -0500 Andrew Shewmaker <agshew@gmail.com> wrote:
> Add user_reserve_pages knob.
>
> Limit the growth of the memory reserved for other user
> processes to min(3% current process, user_reserve_pages).
>
> user_reserve_pages defaults to min(3% free pages, 128MB)
> I arrived at 128MB by taking that max VSZ of sshd, login,
> bash, and top ... then adding the RSS of each.
>
> This only affects OVERCOMMIT_NEVER mode.
Can we have a more complete changelog, please? One which describes, at
great length, *why* we're doing this. Describe the problems you
observed, the possible means of addressing them, why this means is
considered best, etc.
Also, there has been considerable discussion over this patchset and it
is good to update the changelogs to reflect that discussion. Partly
because other people will be asking the same questions when they see
the patches and partly so that reviewers can understand how earlier
objections/suggestions were addressed. Assume that your audience
has not read this email thread!
>From a quick read of the code, it appears that the root-cant-log-in
problem was addressed by simply leaving it up to the administrator,
yes? If the administrator sets user_reserve_pages or
admin_reserve_pages to zero then they risk hitting the root-cant-log-in
problem, yes? If so then I guess this is an OK approach, but we should
clearly describe the risks in the documentation.
Finally, I am allergic to exported interfaces which deal in "pages".
Because PAGE_SIZE can vary by a factor of 16 depending upon config (ie:
architecture). The risk is that a setup script which works nicely on
4k x86_64 will waste memory when executed on a 64k PAGE_SIZE powerpc
box. A smart programmer will recognize this and will adapt the setting
using getpagesize(2), but if we define these things in "bytes" rather
than "pages" then dumb programmers can use it too.
--
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>
next prev parent reply other threads:[~2013-03-12 23:01 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-06 23:52 Andrew Shewmaker
2013-03-12 23:01 ` Andrew Morton [this message]
2013-03-07 1:55 ` Andrew Shewmaker
2013-03-13 21:01 ` 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=20130312160136.b0f09ca7b1b4f2efe01f6617@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=agshew@gmail.com \
--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