From: Andrew Shewmaker <agshew@gmail.com>
To: linux-mm@kvack.org
Cc: linux-kernel@vger.kernel.org
Subject: [RFC PATCH v1 1/1] mm: tuning hardcoded reserved memory
Date: Mon, 25 Feb 2013 18:23:26 -0500 [thread overview]
Message-ID: <20130225232326.GB1704@localhost.localdomain> (raw)
__vm_enough_memory reserves a hardcoded 3% of free memory for other processes
when overcommit is disabled. However, 3% is becoming excessive as memory sizes
increase and memory cgroups provide a more flexible way to manage the issue anyway.
This patch against 3.8 removes the "other" reserve.
I've found that reducing this reserve is beneficial in the case where a system
with overcommit disabled has one primary user that wants to allocate as much
memory as possible with a just few processes.
An additional hardcoded 3% is reserved for root, both when overcommit is enabled
and when it is disabled. I've made it tunable in private patches, and I plan on
submitting some version of them, but I can't decide whether a ratio or a byte
count would be more acceptable. What would people prefer see?
Signed-off-by: Andrew Shewmaker <agshew@gmail.com>
diff --git a/mm/mmap.c b/mm/mmap.c
index 09da0b2..eef9505 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -183,11 +183,6 @@ int __vm_enough_memory(struct mm_struct *mm, long pages, int cap_sys_admin)
allowed -= allowed / 32;
allowed += total_swap_pages;
- /* Don't let a single process grow too big:
- leave 3% of the size of this process for other processes */
- if (mm)
- allowed -= mm->total_vm / 32;
-
if (percpu_counter_read_positive(&vm_committed_as) < allowed)
return 0;
error:
--
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>
reply other threads:[~2013-02-25 23:23 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20130225232326.GB1704@localhost.localdomain \
--to=agshew@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
/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