From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757180AbbA2ULd (ORCPT ); Thu, 29 Jan 2015 15:11:33 -0500 Received: from mail-pa0-f47.google.com ([209.85.220.47]:48032 "EHLO mail-pa0-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754582AbbA2ULc (ORCPT ); Thu, 29 Jan 2015 15:11:32 -0500 Date: Thu, 29 Jan 2015 12:11:47 -0800 From: Andrew Shewmaker To: Roman Gushchin Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrew Morton , Rik van Riel , Konstantin Khlebnikov Subject: Re: [PATCH] mm: don't account shared file pages in user_reserve_pages Message-ID: <20150129201147.GB9331@scruffy> References: <1422532287-23601-1-git-send-email-klamm@yandex-team.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1422532287-23601-1-git-send-email-klamm@yandex-team.ru> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 > Cc: Andrew Morton > Cc: Andrew Shewmaker > Cc: Rik van Riel > Cc: Konstantin Khlebnikov > --- > 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.0 You're two patches conflict, don't they? Maybe you should resend them as a patch series such that they can both be applied? 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. -Andrew