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 ACD69C4345F for ; Fri, 26 Apr 2024 15:32:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 14FB96B00A5; Fri, 26 Apr 2024 11:32:21 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0FF8E6B00A7; Fri, 26 Apr 2024 11:32:21 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F304C6B00A8; Fri, 26 Apr 2024 11:32:20 -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 D458D6B00A5 for ; Fri, 26 Apr 2024 11:32:20 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 90558A1052 for ; Fri, 26 Apr 2024 15:32:20 +0000 (UTC) X-FDA: 82052074440.14.1AA27BA Received: from mail-yb1-f173.google.com (mail-yb1-f173.google.com [209.85.219.173]) by imf11.hostedemail.com (Postfix) with ESMTP id C188E40016 for ; Fri, 26 Apr 2024 15:32:18 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=FRzMml7N; spf=pass (imf11.hostedemail.com: domain of surenb@google.com designates 209.85.219.173 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1714145538; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=AS7F2S8/cotcGn6q7tGA+zdknX79HwQNovwoIzqrUUg=; b=iVguFXpxNlos/Udutqwm0USG4KHydWifDqX0e7N/NJwEd35GLMwUYc17BZY/7Ah1CC89lO DKu3Ab9LBPrNEGDOdMJFoc9RJGE55xFtop5TbuJOEbmCKZ1yvm4IANrXo8afyON83CkTgS zLomlg0uD9u0jVj76mO/mnIE6KSXAfY= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=FRzMml7N; spf=pass (imf11.hostedemail.com: domain of surenb@google.com designates 209.85.219.173 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1714145538; a=rsa-sha256; cv=none; b=ygVs2MknHLR702sk6HDn+Z+U3P8i3AVnlGBJrfEpaxNH5Z4HwTMW/U4ZNaq/ah+QrrCMNY uqD+lZZKruGjjePAo9ZypgYHeRAnsTPjCkilsjHfH6JqkDyPoATu7hkwhAqk3QC3EUAj6D TJlNCcfaih+KUh9GgBSjHULVfFuL+3k= Received: by mail-yb1-f173.google.com with SMTP id 3f1490d57ef6-de477949644so2510918276.1 for ; Fri, 26 Apr 2024 08:32:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1714145538; x=1714750338; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=AS7F2S8/cotcGn6q7tGA+zdknX79HwQNovwoIzqrUUg=; b=FRzMml7NtZCeIdaKhCa/Xt/6nLf2h0plZhp7Yw3/8pGg/U6lLe1KwQhIi7ePyPGNOU 4D+sPhXJ5BPXBRveCcy0eC3FKKq8ohx5H2ZS6uddNo6N/d1VKx/NvGOMtVQNKEv87PvK i4E8hB60hRopAOiqJq49SwGPe3+kXDCJHVivaFJCSkrvo172uANROJ7X/MGqPO/kReQf NYSf8vq70YasubL60GJ1MUUTGCazdGHoCuBlGTSxgl9N4hoihZLjeUGEjP0A1RSUCKf1 CJ84Ws1O6abDMkqYauPSkPTrj988zH+4mX2cCJKKSdXi4goWq4vZde47Y2zOJIV/ekKU ptAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714145538; x=1714750338; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=AS7F2S8/cotcGn6q7tGA+zdknX79HwQNovwoIzqrUUg=; b=tRSVc8tDwCImQnF5znwnyL6nM1o6CJ680fa72FGTdTjw5J5cqZMh8GGiRmIKQtfK+F 8t2k4V6JX/75vtMP0wZobnd9T1crGGEEScShFUxX4PdCkDVdKdZS/jI1vWAfAGj/Pv+G I1Iy7ux4ZyrFz3v/GQQa+OEGwSdesq/dJmEt3Dhy9EUdQvRjBeR9Fwd7PuhQh3U5hqmz mchlqu3mHGe4zBfuIsgV01AoQHP8xWdRmcn/ScNJ0uih4zgSNZ7O70dTDAoJQl2zj6e5 IOLzuAznKiD/oQaRUjaY/lFkSHU448CXQ+ETV4oxzbz4ayqML7Z9CmPQlFRl4rP07pp+ 8ImQ== X-Forwarded-Encrypted: i=1; AJvYcCWnM17SGuKuagIc9q2x+u2uEZcoGkJsS9jVEMmnuca5L0Ag5mzcK8MdilREiMTUCxqAWSQlQ4OhfWh31Nuyn0hF+k4= X-Gm-Message-State: AOJu0YwhFsd2pD1bMxD82Hhu5X3MZOGSoogqed65jvzZhwN4F8SE34QR xsUMkCo9fIcndvlWQ1GTbn4/WxTFvTZCCI1i1CNa1Ybf2Vx4hTcckVkV2eI8Grh2hRwhbpjT2FH XQM50CJpNe96qKLzu+AQM4P5Vmg7eGCiHxhep X-Google-Smtp-Source: AGHT+IEbMHZmUoliwhZDi51Mi8cRiHlfjY/QQEfE15qe+QlxN4TZHCdoAoldZKGr4HHtMlg+YKOHqObI+mDnD/6gxOk= X-Received: by 2002:a25:dbd3:0:b0:de5:ad49:3e2b with SMTP id g202-20020a25dbd3000000b00de5ad493e2bmr2218945ybf.37.1714145537300; Fri, 26 Apr 2024 08:32:17 -0700 (PDT) MIME-Version: 1.0 References: <20240410170621.2011171-1-peterx@redhat.com> <20240411171319.almhz23xulg4f7op@revolver> In-Reply-To: From: Suren Baghdasaryan Date: Fri, 26 Apr 2024 08:32:06 -0700 Message-ID: Subject: Re: [PATCH] mm: Always sanity check anon_vma first for per-vma locks To: Matthew Wilcox Cc: Peter Xu , "Liam R. Howlett" , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Andrew Morton , Lokesh Gidra , Alistair Popple Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: C188E40016 X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: dhswirgbxikf9nzz5qzodighorkpeasm X-HE-Tag: 1714145538-728800 X-HE-Meta: U2FsdGVkX1+BZM/SURZ7mOyowPI6D8hAC4nk5u6skdTrkSLLloEwcBU8vbI/2YvAB/WS1VfEdlrlzOiNNTu14wRvy8Kb870NetIKmtNXEoFKgSurmG49pgZMXMjQ3AzL38N+FHrMmZa0Trpu85knJ8vZUfRe3gy45cfYvzNxcto/D9Zx5+tdJwIDs6KDiGYv+IOHnEa7A7L8c5hCG1FjOs92b90Y56JTt4l2LsJJTMk8AAdjPE8THTCjOPR2zMPkNz6VpESM+FYO+BgPzEZTEfIv2qfAaSPvLppkkaFau+5Ai9bkpmuv3yJYrgU5KmzQVNB+xTxcOjME3bUPpJ0VvhakrPeZ4ThaJEIqbfUKLqYs/O/dknGMhxNcfNBAQZF81MPy+NXYBoxf4UV9jKv5VRxetaojpjFy5PRtD/Lrf61hPkoylbQbjxLm0gKmyft5tBIexD9NBsdgVk2io6qdOhT4QvPplhJ5lNjvBbOHfUGZ4vi5uBrafODCQxSgsccs0GnLTQTudtqa13tveZDyL9nRTXWlXB9By4CI3bVtP9fozmcmJlhapCzLKY+DLs89OAA7oY/khis4qrKkVWP7j+3MeMR4erHjY3cZOn6JKGkxel1Sfq1d50kKn/6KAXnEUq+Bbx5t5D5RNheRAuLo3ocRteWV5+qHNKsWAR5OsbuDZb3QzwcVsP1GqATxtxBSx6mfEAv748vK3bFhGTpX2qrueHNPmcGEMrpCoXS/pYMtCTxmU51dDQtGdWVaqLMzsuaJVh0vHFBJOL8VIMQ1zauz6cG+EuujJGroDhA6pAmGy/tZ1X3g/YFYSYWV7Ss6PNLQ4QjxOr99XefRK0sL90ij/TZRTbi5c+a1zkZJ7rFi4aA+dn+QqlE2pc/Uh0K/RWwOt3HRw7cf0OBLxP4EaM8qfqfXIkypBjma7wcZFC39Ncm7RPe6RobJmvQQ02fyKqh8kfgUNaq1xGUeEm6 uH6N4uhe Gc12PDreMYg/vTmSctR5p+Yy98M2QOdU5KvCkFtIKzDbBxz7n1FPN3coZgoKIXSlRDuhH2jUcWKxTUKXZTlfIlnW2NDFqptJCE0/M3bu8+dldD61eXxHpwRvb99vylAi6mZMKyeVLCM7Ba5dMTgKMveKTconwNmU97g8Kd1wtpo7ury/IsdHhT1nkzOp18kWWWZCh+Gxq+hyFM5C+oS7ld3WhZlvAZHyEozsp1nDyxXvdUsggxbqzLa/b8/qA1znUV/W2rSuFI3H4E+3m9YE/m57oDD5+sZkehDvbJi4oWFe2LAIpCHbrFxifK4aeIV7iwB1ES0GG+jfZP6b6dPgFi4fH+WsvzUgxMIjVUIS+H+uWsqMyVodK3TZ6CcQI/6MW0sr/qnrcyj0ETRo7UwkyuOACDgPeniRXzklIyGnBJXmHZCbwRcSzv5QHwYxzclA06vC1Mwm3VJuMtqD+zMGqi+L9q94uDMa5XKnd X-Bogosity: Ham, tests=bogofilter, spamicity=0.000009, 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 Fri, Apr 26, 2024 at 8:28=E2=80=AFAM Matthew Wilcox wrote: > > On Fri, Apr 26, 2024 at 08:07:45AM -0700, Suren Baghdasaryan wrote: > > On Fri, Apr 26, 2024 at 7:00=E2=80=AFAM Matthew Wilcox wrote: > > > Intel's 0day got back to me with data and it's ridiculously good. > > > Headline figure: over 3x throughput improvement with vm-scalability > > > https://lore.kernel.org/all/202404261055.c5e24608-oliver.sang@intel.c= om/ > > > > > > I can't see why it's that good. It shouldn't be that good. I'm > > > seeing big numbers here: > > > > > > 4366 =C4=85 2% +565.6% 29061 perf-stat.overall.= cycles-between-cache-misses > > > > > > and the code being deleted is only checking vma->vm_ops and > > > vma->anon_vma. Surely that cache line is referenced so frequently > > > during pagefault that deleting a reference here will make no differen= ce > > > at all? > > > > That indeed looks overly good. Sorry, I didn't have a chance to run > > the benchmarks on my side yet because of the ongoing Android bootcamp > > this week. > > No problem. Darn work getting in the way of having fun ;-) > > > > I still don't understand why we have to take the mmap_sem less often. > > > Is there perhaps a VMA for which we have a NULL vm_ops, but don't set > > > an anon_vma on a page fault? > > > > I think the only path in either do_anonymous_page() or > > do_huge_pmd_anonymous_page() that skips calling anon_vma_prepare() is > > the "Use the zero-page for reads" here: > > https://elixir.bootlin.com/linux/latest/source/mm/memory.c#L4265. I > > didn't look into this particular benchmark yet but will try it out > > once I have some time to benchmark your change. > > Yes, Liam and I had just brainstormed that as being a plausible > explanation too. I don't know how frequent it is to use anon memory > read-only. Presumably it must happen often enough that we've bothered > to implement the zero-page optimisation. But probably not nearly as > often as this benchmark makes it happen ;-) I also wonder if some of this improvement can be attributed to the last patch in your series (https://lore.kernel.org/all/20240426144506.1290619-5-willy@infradead.org/)= . I assume it was included in the 0day testing?