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 5F8CDCD1297 for ; Wed, 10 Apr 2024 23:59:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E33986B0088; Wed, 10 Apr 2024 19:59:16 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DE4F86B008A; Wed, 10 Apr 2024 19:59:16 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CAB856B008C; Wed, 10 Apr 2024 19:59:16 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id A94D06B0088 for ; Wed, 10 Apr 2024 19:59:16 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 458DD1C0D6A for ; Wed, 10 Apr 2024 23:59:16 +0000 (UTC) X-FDA: 81995291112.19.070E849 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf19.hostedemail.com (Postfix) with ESMTP id 0E4861A000D for ; Wed, 10 Apr 2024 23:59:13 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=AJFmOhDy; spf=none (imf19.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=1712793554; 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=Oh9geONnOFhFyrtxPHhIzWGAqO2nRJc8KgJoEh6Vr7s=; b=0WDUt/XTMZO6ulfURncZrZbri4US8m5CMMzoE8R64/t2cpgGcxj/XC3d9UJHo7RyMiH+ge n5XAIQXX8HNQd+g/mET1q3UMBZBgkRHrrm0jKu/Y37HK//Ziv4Bi5jIMKmVd+84M6G+3kj 2CTwua5GZMmRqYyBgcharGeYRbLbGNA= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1712793554; a=rsa-sha256; cv=none; b=HD/V1kHasF8kJN2cT2hB+XoxgL5ChoAYqNKpRyOvTSewRI1ku3FB3d9xO87nov6ZtNCXMX l+Qs6mVIJihgtkyVIevM6qWnYvZgaG1x1J1LhHCex0MLaD53CqBpQFNwmrjqBcUIVNkz58 zKsQ7K0ckkFEZ9w3hKbO8rAe5kEdZ4k= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=AJFmOhDy; spf=none (imf19.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=Oh9geONnOFhFyrtxPHhIzWGAqO2nRJc8KgJoEh6Vr7s=; b=AJFmOhDy4PdkswkZTKs462wEa1 Lu/ukDoNsEN6T3i0HFlxvk+AyFJ3r3n1a64GSJMrzX0Mzezv8ckgCw/vUSh3V/p3SYDn2c0WQKT/0 Db/z0S7hN/t8uycwVygZhkj/LB/X5iWRhOfI8B4JjTayb6rG1cAUH+atl89UphV+zjfJXfrA65xlW +78Ih01QSBDUCn43vyJz7CANzkdsyYINaiiPMmCEP5s8LKmCEdCeoWN54vmb7OZBQM2D0dVKeLmGR nO0v++oO/wBcNZIFaBGPke6ujFNnuhZwUqCdmJWs1YP9KPljmKUJlJAid//kcZa9/T+h6wx7Mg9r5 m7HRuUfQ==; Received: from willy by casper.infradead.org with local (Exim 4.97.1 #2 (Red Hat Linux)) id 1ruhqP-00000005a1j-23rB; Wed, 10 Apr 2024 23:59:09 +0000 Date: Thu, 11 Apr 2024 00:59:09 +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: 0E4861A000D X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: kz39rktjmfu4o4kj6o8jprp1z7fadd7b X-HE-Tag: 1712793553-435572 X-HE-Meta: U2FsdGVkX1//3cS+NRQW5mcPELCC1iiZoIIQEs26QneVm1pku9m1Iqo3f93wG+AuWnHpiask7Ix8mhvAytGqyWbGSNHu8WZz9/eN7HNU+7eEeganmxAnWI0eH29EIiwjQtDfSFoMy/qu+JSqy+S7ikgEosCDWxhuftOHnifIgF7cPVda1BXxaQMOlwIm4/uPPiFc/LOlZed3ev7a5FGHQSc8h8GiA2j1pdKbqtY/SSi0h6wAzQrRfkoY9VI7/FgW6ajbQp7UPjk2QFQtt6Mh7/H/ammFM+NOXqicHePmXkB95y6HNmDKX+j3btZoZ99Y3Et/USd7T5Eo31Qvx3EjWJIdaTDUtz32bndh1yrRPS9ZVzzthLvmNGSxVQzBFiaNa7W/4XCxSgpfEUUfPa/RiNViHcK3a56XNGZGlkyrA5t0HS592iJCPjet9nu1gHWP7Wkv5H4aacElc456hoNhOs6XmnApmxN2w92nQD28ng1jzq1m9l3umfa2B1dqvICif7WtZ9R1wlwMNSouHUTDfz2PTbMVsSyZJvMgfxpZO+qbItBoHYJ9u5AXgDS+kml5NHdqc/A1J1t7cUOlqn/5C9P5qbXlMO2Bx1AmbvsEBJ1Vj6VIF4KGu/2LVH2EatrfI8uiTzVB62TZhRbbsb4Fam8ZHb4ZFf+7X6pqY5Q5hw+atEDXe4g+kzPohmksi4pSttbgPXiZMeNIwtqMEwb8HyeAuCBIrBZqzphzf2LYAADYNxMWFJNmWwUsOfkDPrYwgqkX1qsmqL2Y0WvyBvav5ndNe10xz3FXS6TyOnbI8oViILxYZ1J+NqMCKjJdrEWSIbqZoe22A0TiKQYlU/VPDBBR+jeSFstC2cQvTGjxPrxnjwBExtiSxjVXNMoJoQuZUoUi8b3dGNVeSBg5h/YA7Fd9zaJafFe20Z29ocI/s3EZK29ITpU9YDSFaozbwmYxV8V1W+zqkxCWTLvBfRV puxn2WHA Hy6AAu3FH/uHhutYD/oQCmohlPm4bu8A7i1ND4Igx10jdKfrJwGa30OtRNJKH3Y8yube3Ox62WVJ7GRNCS7o2GnNGhwEUiCImh6PLHUOb7qFBqnPBsViScDSOTUy4En43kh8h+jRlWcQHyWMA7+QijTvi2uxmPriQoHUNFY0BDApHFIeFUDKRRXoW+w== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000171, 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 05:23:18PM -0400, Peter Xu wrote: > On Wed, Apr 10, 2024 at 10:10:45PM +0100, Matthew Wilcox wrote: > > > 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. > > Well, I believe you, but even with this, that's a total of 800MB memory on > a giant moster system... probably just to fault in once. > > And even before we talk about that into details.. we're talking about such > giant program running acorss hundreds of cores with hundreds of MB text, > then... hasn't the program developer already considered mlockall() at the > entry of the program? Wouldn't that greatly beneficial already with > whatever granule of locks that a future fault would take? I don't care what your theory is, or even what your benchmarking shows. I had basically the inverse of this patch, and my customer's workload showed significant improvement as a result. Data talks, bullshit walks. Your patch is NAKed and will remain NAKed.