Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757003AbaKTP1H (ORCPT ); Thu, 20 Nov 2014 10:27:07 -0500 Received: from mail-qg0-f43.google.com ([209.85.192.43]:38176 "EHLO mail-qg0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753776AbaKTP1F (ORCPT ); Thu, 20 Nov 2014 10:27:05 -0500 MIME-Version: 1.0 In-Reply-To: References: <502D42E5.7090403@redhat.com> <20120818000312.GA4262@evergreen.ssec.wisc.edu> <502F100A.1080401@redhat.com> <20120822032057.GA30871@google.com> <50345232.4090002@redhat.com> <20130603195003.GA31275@evergreen.ssec.wisc.edu> <20141114163053.GA6547@cosmos.ssec.wisc.edu> <20141117160212.b86d031e1870601240b0131d@linux-foundation.org> <20141118014135.GA17252@cosmos.ssec.wisc.edu> <546AB1F5.6030306@redhat.com> <20141118121936.07b02545a0684b2cc839a10c@linux-foundation.org> <546BDB29.9050403@suse.cz> <546CC0CD.40906@suse.cz> Date: Thu, 20 Nov 2014 16:27:03 +0100 Message-ID: Subject: Re: [PATCH] Repeated fork() causes SLAB to grow without bound From: Michel Lespinasse To: Konstantin Khlebnikov Cc: Vlastimil Babka , Andrew Morton , Rik van Riel , Hugh Dickins , Andrea Arcangeli , Linux Kernel Mailing List , "linux-mm@kvack.org" , Tim Hartrick , Michal Hocko Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Nov 20, 2014 at 3:42 PM, Konstantin Khlebnikov wrote: > On Thu, Nov 20, 2014 at 2:14 AM, Michel Lespinasse wrote: >> On Wed, Nov 19, 2014 at 8:58 AM, Konstantin Khlebnikov wrote: >>> On Wed, Nov 19, 2014 at 7:09 PM, Vlastimil Babka wrote: >>>> Also from reading http://lwn.net/Articles/383162/ I understand that correctness >>>> also depends on the hierarchy and I wonder if there's a danger of reintroducing >>>> a bug like the one described there. >>> >>> If I remember right that was fixed by linking non-exclusively mapped pages to >>> root anon_vma instead of anon_vma from vma where fault has happened. >>> After my patch this still works. Topology hierarchy actually isn't used. >>> Here just one selected "root' anon_vma which dies last. That's all. >> >> That's not how I remember it. > > ??? That at the end of lwn article: > > [quote] > The fix is straightforward; when linking an existing page to an > anon_vma structure, > the kernel needs to pick the one which is highest in the process hierarchy; > that guarantees that the anon_vma will not go away prematurely. > [/quote] > > nowdays this happens in __page_set_anon_rmap(): > > /* > * If the page isn't exclusively mapped into this vma, > * we must use the _oldest_ possible anon_vma for the > * page mapping! > */ > if (!exclusive) > anon_vma = anon_vma->root; > > The rest treeish of topology affects only performance. Ah, I see what you mean. IIRC the !exclusive bit is for pages coming back from swap, where we don't have enough tracking info to remember where the page was first created so we have to assume the worst case (i.e. that it was created in the root anon_vma). My understanding was that we don't exercise this in the non-swap case. Looking back into it, it seems that we are now doing this with ksm and migrate as well, though. The point remains though that moving pages higher than necessary in the anon_vma hierarchy is OK from a correctness perspective but could have bad implications from a performance perspective. -- Michel "Walken" Lespinasse A program is never fully debugged until the last user dies. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/