On 29.01.2015 23:11, Andrew Shewmaker wrote:
On Thu, Jan 29, 2015 at 02:51:27PM +0300, Roman Gushchin wrote:Shared file pages are never accounted in memory overcommit code, so it isn't reasonable to count them in a code that limits the maximal size of a process in OVERCOMMIT_NONE mode. If a process has few large file mappings, the consequent attempts to allocate anonymous memory may unexpectedly fail with -ENOMEM, while there is free memory and overcommit limit if significantly larger than the committed amount (as displayed in /proc/meminfo). The problem is significantly smoothed by commit c9b1d0981fcc ("mm: limit growth of 3% hardcoded other user reserve"), which limits the impact of this check with 128Mb (tunable via sysctl), but it can still be a problem on small machines. Signed-off-by: Roman Gushchin <klamm@xxxxxxxxxxxxxx> Cc: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> Cc: Andrew Shewmaker <agshew@xxxxxxxxx> Cc: Rik van Riel <riel@xxxxxxxxxx> Cc: Konstantin Khlebnikov <khlebnikov@xxxxxxxxxxxxxx> --- mm/mmap.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/mmap.c b/mm/mmap.c index 7f684d5..151fadf 100644 --- a/mm/mmap.c +++ b/mm/mmap.c @@ -220,7 +220,7 @@ int __vm_enough_memory(struct mm_struct *mm, long pages, int cap_sys_admin) */ if (mm) { reserve = sysctl_user_reserve_kbytes >> (PAGE_SHIFT - 10); - allowed -= min(mm->total_vm / 32, reserve); + allowed -= min((mm->total_vm - mm->shared_vm) / 32, reserve); } if (percpu_counter_read_positive(&vm_committed_as) < allowed) -- 2.1.0You're two patches conflict, don't they? Maybe you should resend them as a patch series such that they can both be applied?
I think arithmetic overflow is more important. Upper bound 128M for user reserve makes mis-accounting of shared memory mostly invisible.
Does mm->shared_vm include memory that's mapped MAP_ANONYMOUS in conjunction with MAP_SHARED? If so, then subtracting it could overcommit the system OVERCOMMIT_NEVER mode.
Yep. Moreover shared_vm also includes file mappings with MAP_PRIVATE. It works more likely as "maybe shared", upper bound for "file-rss" (MM_FILEPAGES). I think we need here total size of vmas where VM_ACCOUNT is set -- writable private mappings mapped without MAP_NORESERVE or something like that. But total_vm after limiting with 128Mb gives almost always the same or similar value. So, let's keep it as is. -- Konstantin
-Andrew
-- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>