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 F1D8DCD128A for ; Wed, 10 Apr 2024 21:10:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 447ED6B0083; Wed, 10 Apr 2024 17:10:51 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3F6976B0085; Wed, 10 Apr 2024 17:10:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2E53A6B0087; Wed, 10 Apr 2024 17:10:51 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 107716B0083 for ; Wed, 10 Apr 2024 17:10:51 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 9483816095A for ; Wed, 10 Apr 2024 21:10:50 +0000 (UTC) X-FDA: 81994866660.21.E001D78 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf20.hostedemail.com (Postfix) with ESMTP id 98AC71C0005 for ; Wed, 10 Apr 2024 21:10:48 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=VYrWhooe; spf=none (imf20.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1712783449; 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=K5CZYxkjuGJg+PSt6On95bWBmLHLx24aqSz3YCRWDIc=; b=fQfSs8lOTsEKcEPafWmhg1wD2IlTslkuIVnIm660qE/13Vo9rvl0c4qgM8bg07xWI1mhyy V/feZsEKPdMNCId14FjecvTM8hrQQsFsnBTo/3qbwhTxiA+VWuoWK4PYPvaPDuYRGX93x4 /i7IAHN5xzIjyAGz0IaieeeylX/z22I= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1712783449; a=rsa-sha256; cv=none; b=gweyGDPu/wJd2TrSauuTQUkmWqoeFiN48I1QHLxzuk2llkAL8kQcqdrTIP9Qvyt1dfXmLq eqlQW0ATxd6r0LjGemKqRTCnmlVFCXbF5VUOU+4VlvwCPnEcTfGKlpMYWHgBTHRe4lk/7W ekPnKAP5xcaV9nDXRzK79GQy9bg7Cts= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=VYrWhooe; spf=none (imf20.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none 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=K5CZYxkjuGJg+PSt6On95bWBmLHLx24aqSz3YCRWDIc=; b=VYrWhooeUJjHf7e187qLfGnb1O ve/3a+51OIbesVbgKSCgAQ/z7Qqb6oMwgFwI1Tlhb12X63SDG549nY7P3hENkbJJNFA+jjN/iYYi/ J+KQ8MdM3ycdqdvzzIW6NkVAFu0f58qFZQoazza3i715Nb0Bp2Jm3d+O+j7wG8qw/Frb5y84KFpAt d7VQ4xHVT4m5cM9E83asAWhn6vgrigiIiUdzUb7XSAx1I/SzRWwb5oapebqaSpu/HKWFh54UbBgfX 1RoHGq58pzV+cIutmFqOEM6zEkLPQGHVwf14/8GnaWShYybUjljmkWKXSkmxQolr09ha07zKWByA+ SDN7HFYw==; Received: from willy by casper.infradead.org with local (Exim 4.97.1 #2 (Red Hat Linux)) id 1rufDR-00000005IWD-0qAf; Wed, 10 Apr 2024 21:10:45 +0000 Date: Wed, 10 Apr 2024 22:10:45 +0100 From: Matthew Wilcox To: Peter Xu Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, Andrew Morton , Suren Baghdasaryan , Lokesh Gidra , "Liam R . Howlett" , 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 98AC71C0005 X-Rspam-User: X-Stat-Signature: ac7kt63wfm5jqybq9isqpfzyityseg8z X-Rspamd-Server: rspam03 X-HE-Tag: 1712783448-641493 X-HE-Meta: U2FsdGVkX18AW5snAjEKk4UZC6yBg8bS+5x7UZHGExpIZpHrAZTjTczz1smrEv9zjKqPsJAH2lPS3sHm06h94k490CqD0eAykqAFzUyOOHKRwElvbGiJyeM9K6ZzwwOTtuFyGud4J3rYz0JTMR0BxdCEJgiwoxylILbjfPxOqqFfFy4TlUJwHFVT2DxlOzJnbFaVMhgEDsQOtbPCQ7xUxR+9M+lTSdfMw2q+nTQCcLLYY+xWcywUzdldp8SY4f5DY8EncJ1zL4YOt0M9Kua1XDayZbsZFjccj9U5wLxnqKm+b+pP5CIkbmEvkigLlWQARH2VEVRPy8oXfBjXwy5YSQpJE3/4vyAC2JM3FJlKjaxigPsthKJz/1C8RXhEYJpuvwN1KDj+AeWJMAcdCiTsN0IQSW1xv2m/8T3HlbLfXct0WT2Iozb4KRaHbaespU6uvlYuqiymiVwHLyRPCnInvufFCbgXgdPvjCMFIK7rweU6HOeRpFU6jHjINTq70vovQIQ3DWTr95/RCw4I2xOY22RAtHrQENkRMSu6A+pAMyXWrZ4OezvYYsUXw60xii+hqHrTRnMJHrejqm28JB2epeKbo88ny31LlwAmxrlNCHYDBeBeqo1IQsgsTsr4mrb0882u92Y/nz93UesVNCL8fGNRU9Vz8Nydmp2PrYB96GhE33Z1ObdxTz0cAf/KTV6k3k8ppb8rtOFWZauR7+1sGoemz8JIfi3M15/PTlTCluqMo9HsxSSHLqY6YzrOGJziFIBEkS0R9xX06HSwGRzVNe4TUpUoylqN8IV7AjYxRbSu1KINVJQ0mfyJVGRPlaQITq9PNy3D3ymSmj542Gu3yiLs2jQi0EeyYng5wuYoU/iUDKDES1zKA1kCN849CFS7dMYzz7MgO5sUc9hsZMwrIcF7PMFs4rxrRm6NcgUIpPz/BzBLmS4iHke4MgeLAWmBDNte7kzgnWMeeEez4l3 eVUKeWx1 iNpPlqoH8k9hkupbG12mRsJF8S0l9J4wKS9sQrCgGqKgXFDWOcOQ2BZf96z+NuBsj84sDDEyMOBNDsg+MRpbhZyrW6bcUm4izY8TqfQ64x33OjanluqA8wdbKZllkRP7lamWwHcPH5YPF7OCqbwOOHcBqz/aqGX/SX0IlTeH90vEx+v3y8OsSShreIQ== 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 Wed, Apr 10, 2024 at 04:43:51PM -0400, Peter Xu wrote: > On Wed, Apr 10, 2024 at 09:26:45PM +0100, Matthew Wilcox wrote: > > On Wed, Apr 10, 2024 at 01:06:21PM -0400, Peter Xu wrote: > > > anon_vma is a tricky object in the context of per-vma lock, because it's > > > racy to modify it in that context and mmap lock is needed if it's not > > > stable yet. > > > > I object to this commit message. First, it's not a "sanity check". It's > > a check to see if we already have an anon VMA. Second, it's not "racy > > to modify it" at all. The problem is that we need to look at other > > VMAs, for which we do not hold the lock. > > For that "do not hold locks" part, isn't that "racy"? No. > > > - We may always use mmap lock for the initial READs on a private file > > > mappings, while before this patch it _can_ (only when no WRITE ever > > > happened... but it doesn't make much sense for a MAP_PRIVATE..) do the > > > read fault with per-vma lock. > > > > But that's a super common path! Look at 'cat /proc/self/maps'. All > > your program text (including libraries) is mapped PRIVATE, and never > > written to (except by ptrace, I guess). > > > > NAK this patch. > > We're talking about any vma that will first benefit from a per-vma lock > here, right? > > I think it should be only relevant to some major VMA or bunch of VMAs that > an userspace maps explicitly, then iiuc the goal is we want to reduce the > cache bouncing of the lock when it used to be per-mm, by replacing it with > a finer lock. It doesn't sound right that these libraries even fall into > this category as they should just get loaded soon enough when the program > starts. > > IOW, my understanding is that per-vma lock doesn't benefit from such normal > vmas or simple programs that much; we take either per-vma read lock, or > mmap read lock, and I would expect similar performance when such cache > bouncing isn't heavy. > > I can do some tests later today or tomorrow. Any suggestion you have on > amplifying such effect that you have concern with? 8 socket NUMA system, 800MB text segment, 10,000 threads. No, I'm not joking, that's a real customer workload.