Date:   Mon, 23 Jan 2023 15:38:51 -0500
From:   "Liam R. Howlett" <Liam.Howlett@Oracle.com>
To:     Michal Hocko <mhocko@suse.com>
Cc:     Matthew Wilcox <willy@infradead.org>,
        Suren Baghdasaryan <surenb@google.com>,
        akpm@linux-foundation.org, michel@lespinasse.org,
        jglisse@google.com, vbabka@suse.cz, hannes@cmpxchg.org,
        mgorman@techsingularity.net, dave@stgolabs.net,
        peterz@infradead.org, ldufour@linux.ibm.com,
        laurent.dufour@fr.ibm.com, paulmck@kernel.org, luto@kernel.org,
        songliubraving@fb.com, peterx@redhat.com, david@redhat.com,
        dhowells@redhat.com, hughd@google.com, bigeasy@linutronix.de,
        kent.overstreet@linux.dev, punit.agrawal@bytedance.com,
        lstoakes@gmail.com, peterjung1337@gmail.com, rientjes@google.com,
        axelrasmussen@google.com, joelaf@google.com, minchan@google.com,
        jannh@google.com, shakeelb@google.com, tatashin@google.com,
        edumazet@google.com, gthelen@google.com, gurua@google.com,
        arjunroy@google.com, soheil@google.com, hughlynch@google.com,
        leewalsh@google.com, posk@google.com, linux-mm@kvack.org,
        linux-arm-kernel@lists.infradead.org,
        linuxppc-dev@lists.ozlabs.org, x86@kernel.org,
        linux-kernel@vger.kernel.org, kernel-team@android.com
Subject: Re: [PATCH 39/41] kernel/fork: throttle call_rcu() calls in
 vm_area_free
Message-ID: <20230123203851.227zepvcmwiydqfr@revolver>
Mail-Followup-To: "Liam R. Howlett" <Liam.Howlett@Oracle.com>,
        Michal Hocko <mhocko@suse.com>,
        Matthew Wilcox <willy@infradead.org>,
        Suren Baghdasaryan <surenb@google.com>, akpm@linux-foundation.org,
        michel@lespinasse.org, jglisse@google.com, vbabka@suse.cz,
        hannes@cmpxchg.org, mgorman@techsingularity.net, dave@stgolabs.net,
        peterz@infradead.org, ldufour@linux.ibm.com,
        laurent.dufour@fr.ibm.com, paulmck@kernel.org, luto@kernel.org,
        songliubraving@fb.com, peterx@redhat.com, david@redhat.com,
        dhowells@redhat.com, hughd@google.com, bigeasy@linutronix.de,
        kent.overstreet@linux.dev, punit.agrawal@bytedance.com,
        lstoakes@gmail.com, peterjung1337@gmail.com, rientjes@google.com,
        axelrasmussen@google.com, joelaf@google.com, minchan@google.com,
        jannh@google.com, shakeelb@google.com, tatashin@google.com,
        edumazet@google.com, gthelen@google.com, gurua@google.com,
        arjunroy@google.com, soheil@google.com, hughlynch@google.com,
        leewalsh@google.com, posk@google.com, linux-mm@kvack.org,
        linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org,
        x86@kernel.org, linux-kernel@vger.kernel.org,
        kernel-team@android.com
References: <Y85Z0Ovl68o4cz2j@dhcp22.suse.cz>
 <CAJuCfpG86qc4odkpUbzuROb+jThQgXGWjcFXb0e-c2i0wEGg4g@mail.gmail.com>
 <Y868Fadajv27QMXh@dhcp22.suse.cz>
 <CAJuCfpGSCHpnZwwVV_922fmMBpFPZL0HAHMABuDzMfuURF2sWg@mail.gmail.com>
 <Y87A2CEKAugfgfHC@dhcp22.suse.cz>
 <CAJuCfpGJRZATfc8eUurvV5kGkSNkG=vK=sfwJbU72PESOyATSw@mail.gmail.com>
 <Y87QjHH2aDG5XCGv@casper.infradead.org>
 <Y87djZwQpXazRd00@dhcp22.suse.cz>
 <Y87gY7fhi5OJ35WQ@casper.infradead.org>
 <Y87nVydD7oF9BGMb@dhcp22.suse.cz>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Y87nVydD7oF9BGMb@dhcp22.suse.cz>
User-Agent: NeoMutt/20220429
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?TRNEaPE3fy5PEJ+wCQklGYbg4u9jVh/339PLp4u5KE70A6b0k4eTo7eH7ZpT?=
 =?us-ascii?Q?Gla98kt4Dw0fJBbp608wz8KO2702zffK4SAMZPvwhEowB7CsAooiGMMmz0J1?=
 =?us-ascii?Q?TvZwJy17NRnlBin3GIRmRwmTyzdU/TOpspE1IB3MgQRoW6ziZ22j8MzOqjXJ?=
 =?us-ascii?Q?GWam3eGQ8+shCo+LAJzaiV+Agqm9YTiyePLME7TsznhSgmKx51OSli/qWkol?=
 =?us-ascii?Q?Zk2FTt8MUz5t8WKtA9uQY/D1oNipjeAvVJTGqdSfvTz0ouFygeNQFOXnA4gd?=
 =?us-ascii?Q?neStpkjh8gPLljziSaH4f0gBH2tSi4+N0SqAkO3Q/F0KVB3rJPinD65rxVO8?=
 =?us-ascii?Q?srnIBoOxFwptLKtWK/hWjiwuAj6v9TUPtHekbDViZ+N/vVGa9qKb20KnVdty?=
 =?us-ascii?Q?Ds66Q5benARocBfuLnXs6BLHkghSSTDwgMEkwYCrZYzp6gy0oJZ/1R0x88Ex?=
 =?us-ascii?Q?gIEr+/wTZkLVzh3w5m7S7wbp52xE4OjBZJ5YpSrhm0rkdZeieSRZnnNhLEft?=
 =?us-ascii?Q?pIeczlAE6Smv6IrAez8Z/Mf3QGlp8lTKWEwM4+dRwDxlG8Q/fcHH0ykZiHPH?=
 =?us-ascii?Q?z4xPEnWJXV/AEXpaVRfqrjB1PgsARHWYDsdoAYolvSefJH0sZQPJgXvWUTQA?=
 =?us-ascii?Q?m2tPLqsCN+sygf4x7z9HSFPlo1Y545RXHUQZFPLzWmP4IqJP2e6jI6KAZSgP?=
 =?us-ascii?Q?3Oc/7/AHmdWeZZxxBfntDC6GNEdlEc2q/r7Eeh0uuZhu1VksHyTbOhR7m49a?=
 =?us-ascii?Q?2LMZco3gE3Hll9+GT6QrTsnn1jV2JUqnYLoSRYNcl7/MRSSSUddzx5tw0Zrk?=
 =?us-ascii?Q?6K9ps3EfXmldA8jgPpv/5LE3M5nGZ2ufyQbG8jOlByAxv37jWlDIGPnWMQXi?=
 =?us-ascii?Q?kN1lp32kCCn7am8Eb9MDMF2H0pP+O0BDwJ0bLIlpqAfhaouerck3hXtEygOM?=
 =?us-ascii?Q?8W7FHJvJGulp7CC7QHTjAUemuV8JmZ6fNZfo09vMZzbfdc7QCBukWhbhdIQW?=
 =?us-ascii?Q?2H89IVBvoZ9KrMftfZN+h7JxgPn77OqbEy0eVWIfQjMFHgjS+SJTj982EHiB?=
 =?us-ascii?Q?vxVkrq3UXnrxC09l/IPyFbO+hrQPb1dlRUY9vXkesO+07c7PlAcJ8iiUYZXY?=
 =?us-ascii?Q?ZmPAc+Y4JegmOvW3J0OvrPLm0265miD+9EjbyOQAAFX7lwuCxAGUxkggqW+0?=
 =?us-ascii?Q?2hDF4556dRApbl98cyG6EWp5diYHtApc3ny2uoRnSDv+jlkMYNB5igPzfu9s?=
 =?us-ascii?Q?eT9/h7UGfRpC9rhhZtVCilZEGO/Gdlvk5STURdMoCE8GFUlRsWgcvGMLcGTS?=
 =?us-ascii?Q?HB9UHdafSE9WsOgEj+LL8din3qHutCK+MYBabxdggu19yCrnirmAbkxpfRqh?=
 =?us-ascii?Q?GBJ/dvArSqAcFbeynketnmsFSOE9xio8lqI6hNH4SwbLslDnGscGBGyg1tAl?=
 =?us-ascii?Q?rfy7RL616doI6QbPjRY3zQ2pcjXjmSMjD4O+XhRXsyQzGVtuz322xFN+y/Gd?=
 =?us-ascii?Q?eFyr9ODDEv4AJ6uVY51wDg6RGebKRg5fP14pQJBZ5wmrl7OGzQgPkZ3HdI5w?=
 =?us-ascii?Q?Sei11K+MCmCow1ODdssAtETYmiztd6vDJ+LFtlmxB5J2p/foMhG6SzoKVvSw?=
 =?us-ascii?Q?RQ=3D=3D?=
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: =?us-ascii?Q?jFkY2QXR79CVOLsuiS32dqQxFeU4cGxeyiWvsHVHMsIBd4ujbz+CRKtXsrZf?=
 =?us-ascii?Q?ywsFXbpE/9OR6Zo7uURkoXeJo732GayQkPJNOx4AxQFjPRQHY8qEods3eOcA?=
 =?us-ascii?Q?I8ciKcad2jqoBstgfdMwfU4ltpK5WmtN+7D6Z4/I7sEl66UiMabHvPIIuAP+?=
 =?us-ascii?Q?L45YSN0dFMVO1dw6WEyxL7WCJS7Levcwr1uh9/Ndvd84ml0SFTbs8gwnwjXS?=
 =?us-ascii?Q?8EZ/kc/CsDyr7LkoxJZPG0c2tKZjpqGabkoI5Yb7wSTzHUyqLF596gAulpWs?=
 =?us-ascii?Q?NABN1B/+gRiCGLfWB0tWtCwkG5By+CDgWFlPAFaeUFJ0izTI3olgH9FBlSGb?=
 =?us-ascii?Q?iFclnxJppw6A15PBTfV8sifVa9TGofU+8jW3XbzQjY8ft3L+iL6jfW8C0Ufz?=
 =?us-ascii?Q?qQ7xUt1lb/Vh+53+hD0AiYCaUnVYwqtRjZkJLhhkLVj2pPi2CTg7bhXiBdlB?=
 =?us-ascii?Q?ilA6I3llIZUulW4p7j5+lBNLQxNwrEmuNJ9JX8e+K/w8w69sNuXnzVlNzHYg?=
 =?us-ascii?Q?136TOoezrVOvwCTOfnV5qVFrcDgy6b6BKCZHhYnOyqbwYE2/GYnyxpp3JrPt?=
 =?us-ascii?Q?M+8oxaitDFI5Vj1P8jSbFzuwU8ELSvndLywODXhxNFR7Ayx2jZYfR7KfwuGK?=
 =?us-ascii?Q?C7kGxq8QxZhTHtCzEFb+WA9BeYX5FnjiXPVh3twVT+9YydjayP8JuVtudGC8?=
 =?us-ascii?Q?yq4kD+D2LrCOhZqjZs6ibtJ6x/35Nzr673sIIj5L+PuUAUMDPknhMQELWzuv?=
 =?us-ascii?Q?NdLUhOlNVLujV22ZFjMOgB6mYN0Lh0Hl494f4do1w7z9gcDe1ORHFoxSiUaz?=
 =?us-ascii?Q?p/oAdZ8Pf51RlbYsJ1R0YiJQOBL9k7F0o2vZOo15zrguPB5wk9Cec42tG3KG?=
 =?us-ascii?Q?cXGBzG39NYBF7vg8GFWjOlwAy5FSWWtyzJhKssHJMCQpfIvYQUQli6qccEQ0?=
 =?us-ascii?Q?u8t+APKBOssng1Vzgsm1KFOaKd2dijhXpAld+puTg1YkghO+Eebg32ET45P3?=
 =?us-ascii?Q?ovj+MoqpSz0fHEJFIDSSzerjVd+Ul789lGh7B55b4qbq2s9r27Ql54BSE3zr?=
 =?us-ascii?Q?MHb7CfgYS22wnFlhNWBWCTq7MXtpkPT9Fdh0BsZK+p67g/E3FsGNmUbYwdd1?=
 =?us-ascii?Q?iIIkY/bsXZg2Wrjzwo2cvruH1MGYlwSshjnOpuPQE6d83+4QMf2Wa6KL2yQ/?=
 =?us-ascii?Q?HzoEuf0Wv06RhyzOxvc4tKviCC1uCbAsDbvs6EUhNPRebYE8X+HEwygb5GLY?=
 =?us-ascii?Q?cLGMmTY9NdJp3KptVYEz0q2g34LxDKmWxctE8IyNtFe9Y4ZtdioTsuhC7pOS?=
 =?us-ascii?Q?bxCNSDSP53+zpIIHWmnJX/bQxCq+lwyeDVpV+7QZp2n62ZEntIyLmSrRnZGq?=
 =?us-ascii?Q?2wQpZ51RjZ3XvVjlhx1mv161s62XBe+93kGbQLLWU2yBGZx0wdgILnIIpG8S?=
 =?us-ascii?Q?gi9XJpWgKvCBXvnodrEkqNGAFvLScd34nW5zpn3eOrlN7rtDJ62KLs9RFJ52?=
 =?us-ascii?Q?5o6IaOcqvF8ZwO7nFDOa7ndUS0PhNd2TBp+S?=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 5653e39d-8bcb-4942-37bb-08dafd81d9b3
X-MS-Exchange-CrossTenant-AuthSource: SN6PR10MB3022.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Jan 2023 20:38:57.4793
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: LfLxSRa+S2Y78rPXC3npeZGVVIXliV5KbuCfo/eVplP0UYI27luJqQJYsyYpq6NDrAxOoo2S7KH5XtXkO9lKoQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR10MB4622
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.219,Aquarius:18.0.930,Hydra:6.0.562,FMLib:17.11.122.1
 definitions=2023-01-23_12,2023-01-23_01,2022-06-22_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0
 bulkscore=0 mlxscore=0 mlxlogscore=465 adultscore=0 spamscore=0
 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2212070000 definitions=main-2301230196
X-Proofpoint-ORIG-GUID: T5f6sloYXiQs4Bcfngq21MrCyjx-6X5W
X-Proofpoint-GUID: T5f6sloYXiQs4Bcfngq21MrCyjx-6X5W
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

* Michal Hocko <mhocko@suse.com> [230123 15:00]:
> On Mon 23-01-23 19:30:43, Matthew Wilcox wrote:
> > On Mon, Jan 23, 2023 at 08:18:37PM +0100, Michal Hocko wrote:
> > > On Mon 23-01-23 18:23:08, Matthew Wilcox wrote:
> > > > On Mon, Jan 23, 2023 at 09:46:20AM -0800, Suren Baghdasaryan wrote:
> > > [...]
> > > > > Yes, batching the vmas into a list and draining it in remove_mt() and
> > > > > exit_mmap() as you suggested makes sense to me and is quite simple.
> > > > > Let's do that if nobody has objections.
> > > > 
> > > > I object.  We *know* nobody has a reference to any of the VMAs because
> > > > you have to have a refcount on the mm before you can get a reference
> > > > to a VMA.  If Michal is saying that somebody could do:
> > > > 
> > > > 	mmget(mm);
> > > > 	vma = find_vma(mm);
> > > > 	lock_vma(vma);
> > > > 	mmput(mm);
> > > > 	vma->a = b;
> > > > 	unlock_vma(mm, vma);
> > > > 
> > > > then that's something we'd catch in review -- you obviously can't use
> > > > the mm after you've dropped your reference to it.
> > > 
> > > I am not claiming this is possible now. I do not think we want to have
> > > something like that in the future either but that is really hard to
> > > envision. I am claiming that it is subtle and potentially error prone to
> > > have two different ways of mass vma freeing wrt. locking. Also, don't we
> > > have a very similar situation during last munmaps?
> > 
> > We shouldn't have two ways of mass VMA freeing.  Nobody's suggesting that.
> > There are two cases; there's munmap(), which typically frees a single
> > VMA (yes, theoretically, you can free hundreds of VMAs with a single
> > call which spans multiple VMAs, but in practice that doesn't happen),
> > and there's exit_mmap() which happens on exec() and exit().
> 
> This requires special casing remove_vma for those two different paths
> (exit_mmap and remove_mt).  If you ask me that sounds like a suboptimal
> code to even not handle potential large munmap which might very well be
> a rare thing as you say. But haven't we learned that sooner or later we
> will find out there is somebody that cares afterall? Anyway, this is not
> something I care about all that much. It is just weird to special case
> exit_mmap, if you ask me.

exit_mmap() is already a special case for locking (and statistics).
This exists today to optimize the special exit scenario.  I don't think
it's a question of sub-optimal code but what we can get away without
doing in the case of the process exit.