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 900D4C4345F for ; Fri, 12 Apr 2024 03:14:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 226D86B008A; Thu, 11 Apr 2024 23:14:25 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1D7136B008C; Thu, 11 Apr 2024 23:14:25 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0C6A46B0092; Thu, 11 Apr 2024 23:14:25 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id E42E06B008A for ; Thu, 11 Apr 2024 23:14:24 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 92EF880DAB for ; Fri, 12 Apr 2024 03:14:24 +0000 (UTC) X-FDA: 81999411648.08.80ED76F Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf25.hostedemail.com (Postfix) with ESMTP id 50602A0002 for ; Fri, 12 Apr 2024 03:14:21 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=KtW9kNUd; dmarc=none; spf=none (imf25.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1712891663; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=wPr+h0K5F7dGg0tbz5/EPlcYvQeTFXmy0cKIv+ld4zo=; b=AYzUC0GwlSsRMJ0GcbaJ+aqK7EtCeG356jOHCcZ9nIKgfNhB8xirTM98Thkcl9NFP+aYoo RK6cXYUip4mEaD3HMsFL8GsEwv/D5wWb+pUj7Tl0ANd9Bw+9RxmGYodbFl1y8rf19kJaiq zWldiKV3JYOp0xUlkFu3QDyxG1JoqL4= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=KtW9kNUd; dmarc=none; spf=none (imf25.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1712891663; a=rsa-sha256; cv=none; b=xYZ/fpzxDBL6sd6k+ds0nqPVdwPJBYQ/tUi5GTVHihERnhZ4qQdI0cSJt1ls+XekNCXVEn qlRHUryKFogX8KDI+vu+lZpTuWrpbveqF4oH77Iq5xqUKVLxNUfYXckNhjQA15IvmW6zGP dvV6j3NVgeEfNsN2bd1/wvwGypAbetI= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=wPr+h0K5F7dGg0tbz5/EPlcYvQeTFXmy0cKIv+ld4zo=; b=KtW9kNUd9SNwiVUFb1dvz18ngy fp5w3WqcTYHQz/YeqZZFLfRcnm9XUW+my2nnrFj7DcG4K/NW+A3s5cXEixFmtiEkApmN+he9l6lZC B4/y6LudZkZD5xlRxmfqdNIDoKDCLG7wLor4ZSa7ztXGrtjZIOs9pNP5CCkVrc04SatWQE8iqS5pM 1Sm089TgDyL11WUQGrHTO6R2AtZYywaAoR2+hWycKdhj4n2a99Sc10i9e/Z3FW2cMDh6aeRD3X0E1 k7SbyQupmNi8PXBjSm3EjEk8kZVj3lKHkz3bdugnqVZQV2bZmV9tz4OUFIhQu9VoMM5n81uY7d1vq dw1DlrKQ==; Received: from willy by casper.infradead.org with local (Exim 4.97.1 #2 (Red Hat Linux)) id 1rv7Mn-00000008Hlx-03RU; Fri, 12 Apr 2024 03:14:17 +0000 Date: Fri, 12 Apr 2024 04:14:16 +0100 From: Matthew Wilcox To: Peter Xu Cc: "Liam R. Howlett" , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Andrew Morton , Suren Baghdasaryan , Lokesh Gidra , Alistair Popple Subject: Re: [PATCH] mm: Always sanity check anon_vma first for per-vma locks Message-ID: References: <20240410170621.2011171-1-peterx@redhat.com> <20240411171319.almhz23xulg4f7op@revolver> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 50602A0002 X-Stat-Signature: esufwwmt3wsetpybbdyp3qm4uuf3c5ff X-Rspam-User: X-HE-Tag: 1712891661-216437 X-HE-Meta: U2FsdGVkX1/D/XOXeOXqmycRnFIGqZAO025Qf9gjiZ3/VAdmuKscBH2Gy4URPHQsTpqtZwLhhzN0xFggN/qF/PIcDFE1xbIDl7MrJ3zxm72W6fGQH9zhPm+tWjnI41kA60cM1yh88vtXZWoWFPxe93EfG7fu/y9rYO9BmTJgvY0cpuDkGcghXZwcJUtEO1bQf8SAvPjZqP6wOXydplXITl19x7eKqfD475Qv4HVQKN+bG/Q8GcGPP96hM0XwGrS9k85wETFcyo2ZEvFliBcDPSp/qMk+jNIu/ofogD28v6vy/RukTGe5e9gG7crRhvgnwXmLkW2VETcjKnF+9X5MlMZnsRcYoEaJiHzd82p6WUNJxkE3+hnrHJ8qWV7cdvI+xb3WM6C4sTNbIeNh0gCaKCm3k37Q16HX5pycIDnIexUR2LngzwJWN+Mw0cjkvt6L84/SVfh1jfidhddbJjMRKaxy8ugffv3ajiUWjE58Ob3OFK7/aYgt0Ff2oQPQW9HUmiXZN+cb38VRb4+Nqd3LEDulyMSXy7VNswNpn2H/FmGVS55xr8KCdhygFsePH+G6RXy+5CGCanxJSRvEUkkwC6GnUplmTZWlKuEmePRoXMzO0D6mtD1rmACNv1r9DMt5TsEFZ66tAVp07Fj5zK65tpJ5ng5ZKfVme8VmP2fXsEsFNw7gw7SK5s+Jvb2s34UHiiK+w8unkB+N4rKdV82zAEv/a3Ap4LjXBT3zG8t6dPdKhkAlr8Qoxc4qsD9REqX5YRJqvaVds2TrJ4v1NCJD8j1Y0rKuuV3avrMmJkj/cY8k37peug//IG2wOXKN0qjY/xkVy6tLEmZBIdH2iMBRvkWwshlOcu1GrrbomaZlNL5RXCygOUBkeg6eWZYXZLuRMqZ6FTp6s+i3022Q4HScZm3jO9LmcZFC3zRscKvHcXojzJjpgUH+JnjGM9p+PedMhrGgkEpMfOmVBh1ZOCo aAPDK6a+ wCgV+BtpdkMB69hEI+fyZZV0RyiR42oJbEnTIguTbDJEfuzU3Qu/Y9vfm+G0JPTY2c/JW1G+ms1FpxCU1gdS7Wa6hH9i+LLcMfjulLaBwQqFKUHMU9FvmIQEoNgOqcdmul4IjyRUy+WQ30uAe3gupjUb+izw1bGS9D2LY6BvRt4vKNvN+QiIp5wibTw== 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: List-Subscribe: List-Unsubscribe: On Thu, Apr 11, 2024 at 11:02:32PM +0100, Matthew Wilcox wrote: > > How many instructions it takes for a late RETRY for WRITEs to private file > > mappings, fallback to mmap_sem? > > Doesn't matter. That happens _once_ per VMA, and it's dwarfed by the > cost of allocating and initialising the COWed page. You're adding > instructions to every single page fault. I'm not happy that we had to > add extra instructions to the fault path for single-threaded programs, > but we at least had the justification that we were improving scalability > on large systems. Your excuse is "it makes the code cleaner". And > honestly, I don't think it even does that. Suren, what would you think to this? diff --git a/mm/memory.c b/mm/memory.c index 6e2fe960473d..e495adcbe968 100644 --- a/mm/memory.c +++ b/mm/memory.c @@ -5821,15 +5821,6 @@ struct vm_area_struct *lock_vma_under_rcu(struct mm_struct *mm, if (!vma_start_read(vma)) goto inval; - /* - * find_mergeable_anon_vma uses adjacent vmas which are not locked. - * This check must happen after vma_start_read(); otherwise, a - * concurrent mremap() with MREMAP_DONTUNMAP could dissociate the VMA - * from its anon_vma. - */ - if (unlikely(vma_is_anonymous(vma) && !vma->anon_vma)) - goto inval_end_read; - /* Check since vm_start/vm_end might change before we lock the VMA */ if (unlikely(address < vma->vm_start || address >= vma->vm_end)) goto inval_end_read; That takes a few insns out of the page fault path (good!) at the cost of one extra trip around the fault handler for the first fault on an anon vma. It makes the file & anon paths more similar to each other (good!) We'd need some data to be sure it's really a win, but less code is always good. We could even eagerly initialise vma->anon_vma for anon vmas. I don't know why we don't do that.