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 1A81CC5B555 for ; Mon, 2 Jun 2025 18:02:12 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9DC6D6B030B; Mon, 2 Jun 2025 14:02:11 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9B49B6B030C; Mon, 2 Jun 2025 14:02:11 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8CB016B030D; Mon, 2 Jun 2025 14:02:11 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 740236B030B for ; Mon, 2 Jun 2025 14:02:11 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id DDE1FEDEA5 for ; Mon, 2 Jun 2025 18:02:10 +0000 (UTC) X-FDA: 83511229620.22.E390741 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf30.hostedemail.com (Postfix) with ESMTP id 2FB0E80010 for ; Mon, 2 Jun 2025 18:02:06 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b="fx2S/uS+"; spf=none (imf30.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=1748887329; 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=wNLQufEp1rJXsH/GI5NA0ro279s3D/mfj5DLODR5rBg=; b=yIz5nQYpx1hIAW4AoL0xIE35aJYNh9N0ZB73guWdmQWs+Fq/l15YAapta/fONPiZ0waVdl ZXuM851t0tCUm+A1RJLHdmD77Oi3JJkUvsf1UynFFtMMnDhvfMGJNV0v32dXieBDkz+Am4 uXX3IoTOghCqG/dRHie1COiwnGEJO6U= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b="fx2S/uS+"; spf=none (imf30.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-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1748887329; a=rsa-sha256; cv=none; b=PAFXQIi4jNHNj7VGt6J3+v5R2M/hJ+dwgIg+JwZNuDLk/cN3A9+ngDQB49DULhU2L6xSA0 Na66VCn/eAmHKUQnI/aQ7l+rjWQPaqJVif1G2W9OburvDWuiofTfbuuDAzxu7dNcof6mKI t4m44SNaKJJHJ3wn65tZzvvfyj1vM6s= 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=wNLQufEp1rJXsH/GI5NA0ro279s3D/mfj5DLODR5rBg=; b=fx2S/uS+FrK8cpSVxGwbBq0XeR 6QGGYf/wYPYmAT6H9FqucyWErsUWDjNoaJYY0TmVMu1wN5uOALwGSRHjeQcxjFbOVlBRhQxHrSPZn iXKD52YYUfKrIpOP63a06xbO3BjEn2VM8KJWUMeNWEArkC4Z30HNcmZWRymX+s/rPUcR/K6S2qMPt GGn7/NirTXLYAfJq3VYXkfTayEnYr/BYgPXGPeb15qrihHEUZoMlHCvhYVd3LdPPxk0MGja3jS/i8 NU2iz6hnAnBwYkd4XAGRjDhppFLeT2AOVgKsm/NuD4wdRC4Kpz49p6ePiVaJumtrxjIp8LinLuYms dhWV0ZTw==; Received: from willy by casper.infradead.org with local (Exim 4.98.2 #2 (Red Hat Linux)) id 1uM9Tw-00000001C7d-2dSv; Mon, 02 Jun 2025 18:01:56 +0000 Date: Mon, 2 Jun 2025 19:01:56 +0100 From: Matthew Wilcox To: Johannes Weiner Cc: Lorenzo Stoakes , Andrew Morton , Shakeel Butt , "Liam R . Howlett" , David Hildenbrand , Vlastimil Babka , Jann Horn , Arnd Bergmann , Christian Brauner , SeongJae Park , Usama Arif , Mike Rapoport , Barry Song <21cnbao@gmail.com>, linux-mm@kvack.org, linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org, linux-api@vger.kernel.org, Pedro Falcato Subject: Re: [DISCUSSION] proposed mctl() API Message-ID: References: <85778a76-7dc8-4ea8-8827-acb45f74ee05@lucifer.local> <20250529211423.GA1271329@cmpxchg.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250529211423.GA1271329@cmpxchg.org> X-Stat-Signature: ankuhwqzp8oj9sh4npmcooamhtdifiku X-Rspamd-Queue-Id: 2FB0E80010 X-Rspam-User: X-Rspamd-Server: rspam02 X-HE-Tag: 1748887326-775138 X-HE-Meta: U2FsdGVkX1/1AGsOBklojQZ2OcfJ6Bd0v7/wc4Tud5YQUulwAkTsUJZpDCo0EB3yLzS8+ovmGl4PXhdx5A2kMCcOdkaeYQyOk2WM++FKedW4Gw3IVpfMaKLiwY1P5By1Rlm8ZBorCs2jmeIorFha7S6NUpFdL5kca2xdHv1gy04s0SQdCSgv9ZiHIu+i8yAk0Ce4qfidIsTCQ4fOULYJrGUfTnNh5AM/ojTqsuRqNXrFnLqutUe1Z3qoVOF6TkZxrkHAGTyHMFaf3N7irYJe0YFVW329fzXnxZuXZgmYUtq5LLs62A2ryISIa7ugAYkm13dAryJtJ2ds/xK2DEGJOjwgwIxs+1JHundDHJFwcLz7FdBChLYZlAszQi1aDikh68y4pvtfGM0Y3uFrtl0hyc8vBsltq6/8kPVEuuMZGdgkrvr8e1kD23ZBDeiS5/9Z00dQfQmndUUxY2unMs1rUYF+IDCitSvDTd5+n6RXNOIbSkryuMc0ZQE+VaDIuDsbMLq8iNmSsZKS4jWN9uTyDrtRKIZnBKY6rS01YrfmiBcdbh7SW5QeTo6YszKVos2zG766tdmVpW56z/+L03FV7OcDEIegLVoIWY2vu+5vqpGkphSY2f5exXHL3Ea44E7JpISt2mN4ylVYmWbQ6f85yR3nt6Lo9dJ6ZPNOCT7qHuzExvnPBPfB/zXeToju5lLls/TxwaOfaVDy9QCsLluXfHIqYaJz9ivmCsw0F6aSOC1bGNOukZOwWO3kLaz3bR2FjTPsqXMEHAlfyybijqxSsrdkWNZZR18M2awCRw3xyQH6+v5hVL8tiVznlcsvHfN0xsuo8kVaIOkaOb8noohcbp6pSEjefd388G9dYHTVmsehhVWRAO2sbztGagxfnyHj6NwHUxwBrHfV/MO2n1fpU5Y3YjmtySCJ6mnR0dM4lX3ohNQ5cLPySY/sh/GQs2C+wKAwv2vpCaSJWzez60g mr/wC0I3 Bo1GYI/ovGpFjrBKHSE8z6s7o3EKHWkR9Xlquaw/Llki/fVSG3AF6ZwPK/u/mn25KLiPV8AIYuqqlGAFOq6NM1hWCX7ZUs8kuUGuQjqjNUIUwjfi7KhzFR4KEuZwFmIZ1JQEK6ZsrPpqx81Ey6qHFAQcXt1HhypmZ3JOS6g/itMuc0AbzkSGNbXX2uuy87yK50h/QuC+flNqQM+5WA+77x5JpOW16IOrDz6cgLk11Z8vVcz8= 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, May 29, 2025 at 05:14:23PM -0400, Johannes Weiner wrote: > On Thu, May 29, 2025 at 04:28:46PM +0100, Matthew Wilcox wrote: > > Barry's problem is that we're all nervous about possibly regressing > > performance on some unknown workloads. Just try Barry's proposal, see > > if anyone actually compains or if we're just afraid of our own shadows. > > I actually explained why I think this is a terrible idea. But okay, I > tried the patch anyway. Sorry, I must've missed that one ;-( > This is 'git log' on a hot kernel repo after a large IO stream: > > VANILLA BARRY > Real time 49.93 ( +0.00%) 60.36 ( +20.48%) > User time 32.10 ( +0.00%) 32.09 ( -0.04%) > System time 14.41 ( +0.00%) 14.64 ( +1.50%) > pgmajfault 9227.00 ( +0.00%) 18390.00 ( +99.30%) > workingset_refault_file 184.00 ( +0.00%) 236899.00 (+127954.05%) > > Clearly we can't generally ignore page cache hits just because the > mmaps() are intermittent. > > The whole point is to cache across processes and their various > apertures into a common, long-lived filesystem space. > > Barry knows something about the relationship between certain processes > and certain files that he could exploit with MADV_COLD-on-exit > semantics. But that's not something the kernel can safely assume. Not > without defeating the page cache for an entire class of file accesses. So what about distinguishing between exited-normally processes (ie git log) vs killed-by-oom processes (ie Barry's usecase)? Update the referenced bit in the first case and not the second?