From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id C65D1C433EF for ; Wed, 15 Dec 2021 13:05:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 357B16B0073; Wed, 15 Dec 2021 08:05:31 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 3072B6B0074; Wed, 15 Dec 2021 08:05:31 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1A8CF6B0075; Wed, 15 Dec 2021 08:05:31 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0138.hostedemail.com [216.40.44.138]) by kanga.kvack.org (Postfix) with ESMTP id 0D3FB6B0073 for ; Wed, 15 Dec 2021 08:05:31 -0500 (EST) Received: from smtpin30.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id C792388485 for ; Wed, 15 Dec 2021 13:05:20 +0000 (UTC) X-FDA: 78920049600.30.774932C Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf24.hostedemail.com (Postfix) with ESMTP id B7DD6180017 for ; Wed, 15 Dec 2021 13:05:17 +0000 (UTC) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id E48E5210F9; Wed, 15 Dec 2021 13:05:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1639573518; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=4WZ7nRsuN4bYhjGYGsm47Qu2gogklXkj+EKNuYHnkws=; b=J6B0+a9DJfkCACkP88ddk6JSJuUUhF4fjAFg/nt20Jpuui4FmUV5I/u/yWoeg6/9p2s4Zr xIRxFB7bMTqhcLh7eQcVfPhXp+9BszglpQ+5XYkz1bNCBmsukPntv9x7caQ7Po3rSVha8j U/PC4611ge1+exTk9d5SSGczCSqfrX8= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1639573518; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=4WZ7nRsuN4bYhjGYGsm47Qu2gogklXkj+EKNuYHnkws=; b=L6SCc7mRFgXJJTauzA/J5DTKgZH14kayFsjdNpeqwqXV1dlXv2wFx3EikV+GLrP2Rgr43O g42EpK2umnd7BpAQ== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id A1E4E1330B; Wed, 15 Dec 2021 13:05:18 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id fznBJg7ouWFiQQAAMHmgww (envelope-from ); Wed, 15 Dec 2021 13:05:18 +0000 Message-ID: <4207b5a3-efac-40f3-6b42-6713c9283cdd@suse.cz> Date: Wed, 15 Dec 2021 14:05:18 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Content-Language: en-US To: Liam Howlett , "maple-tree@lists.infradead.org" , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , Andrew Morton Cc: Song Liu , Davidlohr Bueso , "Paul E . McKenney" , Matthew Wilcox , Laurent Dufour , David Rientjes , Axel Rasmussen , Suren Baghdasaryan , Rik van Riel , Peter Zijlstra , Michel Lespinasse , Jerome Glisse , Minchan Kim , Joel Fernandes , Rom Lemarchand References: <20211201142918.921493-1-Liam.Howlett@oracle.com> <20211201142918.921493-10-Liam.Howlett@oracle.com> From: Vlastimil Babka Subject: Re: [PATCH v4 09/66] mm/mmap: Use the maple tree in find_vma() instead of the rbtree. In-Reply-To: <20211201142918.921493-10-Liam.Howlett@oracle.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=J6B0+a9D; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=L6SCc7mR; spf=pass (imf24.hostedemail.com: domain of vbabka@suse.cz designates 195.135.220.28 as permitted sender) smtp.mailfrom=vbabka@suse.cz; dmarc=none X-Rspamd-Queue-Id: B7DD6180017 X-Stat-Signature: iar5a55d4tqm6aidewt9oj7mxq3bbsid X-Rspamd-Server: rspam04 X-HE-Tag: 1639573517-521499 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 12/1/21 15:29, Liam Howlett wrote: > From: "Liam R. Howlett" > > Using the maple tree interface mt_find() will handle the RCU locking and > will start searching at the address up to the limit, ULONG_MAX in this > case. > > Add kernel documentation to this API. > > Signed-off-by: Liam R. Howlett Acked-by: Vlastimil Babka Note below: > --- > mm/mmap.c | 27 +++++++++------------------ > 1 file changed, 9 insertions(+), 18 deletions(-) > > diff --git a/mm/mmap.c b/mm/mmap.c > index de78fc0ce809..6a7502f74190 100644 > --- a/mm/mmap.c > +++ b/mm/mmap.c > @@ -2429,10 +2429,16 @@ get_unmapped_area(struct file *file, unsigned long addr, unsigned long len, > > EXPORT_SYMBOL(get_unmapped_area); > > -/* Look up the first VMA which satisfies addr < vm_end, NULL if none. */ > +/** > + * find_vma() - Find the VMA for a given address, or the next vma. > + * @mm: The mm_struct to check > + * @addr: The address > + * > + * Returns: The VMA associated with addr, or the next vma. > + * May return %NULL in the case of no vma at addr or above. > + */ > struct vm_area_struct *find_vma(struct mm_struct *mm, unsigned long addr) > { > - struct rb_node *rb_node; > struct vm_area_struct *vma; > > mmap_assert_locked(mm); > @@ -2441,22 +2447,7 @@ struct vm_area_struct *find_vma(struct mm_struct *mm, unsigned long addr) > if (likely(vma)) > return vma; > > - rb_node = mm->mm_rb.rb_node; > - > - while (rb_node) { > - struct vm_area_struct *tmp; > - > - tmp = rb_entry(rb_node, struct vm_area_struct, vm_rb); > - > - if (tmp->vm_end > addr) { > - vma = tmp; > - if (tmp->vm_start <= addr) > - break; > - rb_node = rb_node->rb_left; > - } else > - rb_node = rb_node->rb_right; > - } > - > + vma = mt_find(&mm->mm_mt, &addr, ULONG_MAX); This updates addr to the end of vma->vm_end. > if (vma) > vmacache_update(addr, vma); And here vmacache is updated with the updated addr, which wasn't done before. This AFAIU has two consequences: - the original addr will not be cached, so this whole vma lookup will not be cached and will always resort to maple tree search. Possibly affecting any measurements you made. Especially the vmacache removal later in the series might now look like it makes not much of a performance difference - but vmcache is effectively dysfunctional. - the future lookup of address vma->vm_end will return this vma, although the address doesn't belong to it. Wouldn't be surprised if this caused infrequent mysterious bugs? Both will resolve with vmacache removal later, but better still fix this. Vlastimil > return vma;