Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp3378530ybl; Sun, 12 Jan 2020 16:37:25 -0800 (PST) X-Google-Smtp-Source: APXvYqyMYkdhq4r4V5gv3KzwVM28mwEeUzHsBf6iCR6s9Sfjl5FtzJZRfDkGIs0GmVbSueWcNkLj X-Received: by 2002:a05:6830:1e37:: with SMTP id t23mr11618361otr.16.1578875845889; Sun, 12 Jan 2020 16:37:25 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1578875845; cv=none; d=google.com; s=arc-20160816; b=NLc7K+0zwcNIObRUog9iyXDdcJDAnkHSfw7PxmzTA3ZYaSRjA0Sfs+o/dS8Bouvrxm 2jWLmlNtVRqQ1/d51zFPeaq5SLIQIz8Q//xTwifP+hYEd82HpICtOwerz1KwGc1turq1 S1J0sIaTDRoFzazvhyZZ12zau0tLk499WbFzmTGbbGOQeYLPymfxeIBjn6rTtB0lHv98 w0YHnHvujHFc9sTo5cw19UufhATBG265sfJa9zSVUAoP7qY98L11YVJAxH95S1uNo4sE 9u+3vJY4xx/VZylbVpCUG348ebQNSldUk9shmx92cFugFWOwX1T4DcMszi5TyPhgRXUR pKGA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:reply-to:message-id:subject:cc:to:from:date; bh=wYgJfSVsqNQEgbWJQhzAGtnkvynfYJo3QrZV2LMEEEM=; b=K88z2nhDeElzz8uD3fYBJVYq3x030XIzjuQCY4r7GRPMTMTU2XkZKBGRBfQUNEEhnN ok+yZuoj8afHhVKLLBRC2AcbCFvweVHBVlQT3v3gjMpjFPAMiRkfQ+ECyEFXzHprPnCG TUQ+ynUuCMhj2eIFYsJs6WkF9gks5LHFOhocsX5qIeIiMeQ2KsDV5l9k4L5V/tCowePA 6KGC9l+Ti5k0hL24gWiv2lt1BJHKtTrXiQvnhVLXbjuASeQt+XWbsE75fH/vxuty45rp /+2YO8ets7SvJ4Fl6k0gm147PO8y76U0RP4ukGcQU8hc1CmR5iRBUsU+eP5EL+N3rs9V v+eg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id n14si6213142otk.179.2020.01.12.16.37.13; Sun, 12 Jan 2020 16:37:25 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2387547AbgAMAdw (ORCPT + 99 others); Sun, 12 Jan 2020 19:33:52 -0500 Received: from mga18.intel.com ([134.134.136.126]:50230 "EHLO mga18.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2387493AbgAMAdw (ORCPT ); Sun, 12 Jan 2020 19:33:52 -0500 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga106.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Jan 2020 16:33:51 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.69,426,1571727600"; d="scan'208";a="272897797" Received: from richard.sh.intel.com (HELO localhost) ([10.239.159.54]) by FMSMGA003.fm.intel.com with ESMTP; 12 Jan 2020 16:33:49 -0800 Date: Mon, 13 Jan 2020 08:33:43 +0800 From: Wei Yang To: Konstantin Khlebnikov Cc: Wei Yang , Li Xinhai , "linux-mm@kvack.org" , akpm , "linux-kernel@vger.kernel.org" , Rik van Riel , "kirill.shutemov" Subject: Re: [PATCH v2 1/2] mm/rmap: fix and simplify reusing mergeable anon_vma as parent when fork Message-ID: <20200113003343.GA27210@richard> Reply-To: Wei Yang References: <20200108023211.GC13943@richard> <20200109025240.GA2000@richard> <20200110023029.GB16823@richard> <20200110112357351531132@gmail.com> <20200110053442.GA27846@richard> <20200111223820.GA15506@richard> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Jan 12, 2020 at 12:55:45PM +0300, Konstantin Khlebnikov wrote: > > >On 12/01/2020 01.38, Wei Yang wrote: >> On Fri, Jan 10, 2020 at 11:11:23AM +0300, Konstantin Khlebnikov wrote: >> [...] >> > > > > > >> > > > > > series of vma in parent with shared AV: >> > > > > > >> > > > > > SRC1 - AV0 >> > > > > > SRC2 - AV0 >> > > > > > SRC3 - AV0 >> > > > > > ... >> > > > > > SRCn - AV0 >> > > > > > >> > > > > > in child after fork >> > > > > > >> > > > > > DST1 - AV_OLD_1 (some old vma, picked by anon_vma_clone) plus DST1 is attached to same AVs as SRC1 >> > > > > > DST2 - AV_OLD_2 (other old vma) plus DST1 is attached to same AVs as SRC2 >> > > > > > DST2 - AV1 prev AV parent does not match AV0, no old vma found for reusing -> allocate new one (child of AV0) >> > > > > > DST3 - AV1 - DST2->AV->parent == SRC3->AV (AV0) -> share AV with prev >> > > > > > DST4 - AV1 - same thing >> > > > > > ... >> > > > > > DSTn - AV1 >> > > > > > >> >> To focus on the point, I rearranged the order a little. Suppose your following >> comments is explaining the above behavior. >> >> I've illustrated how two heuristics (reusing-old and sharing-prev) _could_ work together. >> But they both are optional. >> At cloning first vma SRC1 -> DST1 there is no prev to share anon vma, >> thus works common code which _could_ reuse old vma because it have to. >> If there is no old anon-vma which have to be reused then DST1 will allocate >> new anon-vma (AV1) and it will be used by DST2 and so on like on your picture. >> >> I agree with your 3rd paragraph, but confused with 2nd. >> >> At cloning first vma SRC1 -> DST1, there is no prev so anon_vma_clone() would >> pick up a reusable anon_vma. Here you named it AV_OLD_1. This looks good to >> me. But I am not sure why you would picked up AV_OLD_2 for DST2? In parent, >> SRC1 and SRC2 has the same anon_vma, AV0. So in child, DST1 and DST2 could >> also share the same anon_vma, AV_OLD_1. >> >> Sorry for my poor understanding, would you mind giving me more hint on this >> change? > >For DST2 heuristic "share-with-prev" will not work because if prev (DST1) >uses old AV (AV_OLD_1) and AV_OLD_1->parent isn't SRC2->AV (AV0). >So DST2 could only pick another old AV or allocate new. I know this behavior after your change, my question is why you want to do so. > >My patch uses condition dst->prev->anon_vma->parent == src->anon_vma rather >than obvious src->prev->anon_vma == src->anon_vma because in this way it >eliminates all unwanted corner cases and explicitly verifies that we going to >share related anon-vma. > This do eliminates some corner case, but as you showed child and parent don't share the same AV topology. To keep the same AV topology is the purpose of my commit. I agree you found some bug that previous commit doesn't do it is expected. But since you change the design a little, I suggest you split this idea to a separate patch so that reviewer and audience in the future could understand your approach clearly. Otherwise audience would be confused and hard to track this change. For example, you describe the behavior after your change. The second vma would probably have a different AV from first vma. >Heuristic "reuse-old" uses fact that VMA links and AV parent chain are tracked >independently: when VMA reuses old AV it still links to all related AV even >if VMA->AV points into some old AV in the middle of inheritance chain. > >> >> > > > > >> > > > > Yes, your code works for DST3..DSTn. They will pick up AV1 since >> > > > > (DST2->AV->parent == SRC3->AV). >> > > > > >> > > > > My question is why DST1 and DST2 has different AV? The purpose of my patch >> > > > > tries to make child has the same topology and parent. So the ideal look of >> > > > > child is: >> > > > > >> > > > > DST1 - AV1 >> > > > > DST2 - AV1 >> > > > > DST2 - AV1 >> > > > > DST3 - AV1 >> > > > > DST4 - AV1 >> > > > > >> > > > > Would you mind putting more words on DST1 and DST2? I didn't fully understand >> > > > > the logic here. >> > > > > >> > > > > Thanks >> > > > > >> > > > >> > > > I think that the first version is doing the work as you expected, but been >> > > > revised in second version, to limits the number of users of reused old >> > > > anon(which?is picked?in anon_vma_clone() and keep the tree structure. >> > > > >> > > >> > > Any reason to reduce the reuse? Maybe I lost some point. >> > >> > > >> > > > > -- >> > > > > Wei Yang >> > > > > Help you, Help me >> > > >> -- Wei Yang Help you, Help me