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 22E91C369BD for ; Thu, 17 Apr 2025 02:43:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 828672800E3; Wed, 16 Apr 2025 22:43:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7D6142800CE; Wed, 16 Apr 2025 22:43:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6C3E62800E3; Wed, 16 Apr 2025 22:43:34 -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 4FD012800CE for ; Wed, 16 Apr 2025 22:43:34 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 7245DB3308 for ; Thu, 17 Apr 2025 02:43:34 +0000 (UTC) X-FDA: 83341989948.01.CFFDED4 Received: from mail-vk1-f177.google.com (mail-vk1-f177.google.com [209.85.221.177]) by imf16.hostedemail.com (Postfix) with ESMTP id 947CA180010 for ; Thu, 17 Apr 2025 02:43:32 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=OxqnBvBw; spf=pass (imf16.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.221.177 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1744857812; 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=Od8k6LZA8WtpjFMRC9gzixGp04UToT1Q0Y0i08AB8fY=; b=eiahitt8a0j20R//UKs8IH1xP2wJPvvs8YZE8CWVswzB0yk9D7S4CqQl2uyPtqD3rCUZVC qhqSn4MmicTrDqsSLvcuecYGRzr1YwjSuXJ5aq3kDDVhHiahFVSWXHoz+l6qSmWjvoX2/m /JjKCKis+L2oVXYO43A9czF0SBA+NQQ= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=OxqnBvBw; spf=pass (imf16.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.221.177 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1744857812; a=rsa-sha256; cv=none; b=Hi9j3K3K+O8YWhZYlfuJmXJsps+eFjzD5CrcEoh90HfT6uEr/hrbCNoGvCpxeWiYK2jgaE jr48qC/ICMYzVEJUgyWK9p3cU7WCKETMfijun572piVGinEAwfDGbnaWHr2YcRQczjlABh sVABn3lySq9wHmbN/oPh3aKoMTNNfkk= Received: by mail-vk1-f177.google.com with SMTP id 71dfb90a1353d-5240764f7c1so123802e0c.2 for ; Wed, 16 Apr 2025 19:43:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1744857811; x=1745462611; 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=Od8k6LZA8WtpjFMRC9gzixGp04UToT1Q0Y0i08AB8fY=; b=OxqnBvBwGweMEwXKcO2XJeYOc9Re/+sW8WNcGFTSTYrQuMRkc3PhEHb5/vMAUcyuJo Tt/zYy42EukW4XQ3YvZRStDMcb/9PgZEXmvd1U9KamfvuPxQy+wpQcMy3HdIchCJ3S4j XX9dRz2FMe9aCePC3OjybxPTE8ZQIKyNCTRrqDoFWR0ND4bttGSi6fw6mTSJ2mgfe2LL D1v/0CSswB2BXSIRyD3bSX8LLjD++b+zyEOYye7yfdKFlDwfynwQuIKJTU7f/71QSYUw idJV9TMyQaa3b3SqlRh7DTU0D1W6pfo07n+k6rv6ocdC2+XpMUTVSLbFVeoIid6+X8F5 Titw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1744857811; x=1745462611; 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=Od8k6LZA8WtpjFMRC9gzixGp04UToT1Q0Y0i08AB8fY=; b=n7yJFPUz4n375RL+q0gm3ifUhWQyFsnOyh53ZeJ6dVmBGLNt6w9RzkxgZwQXMKBt+s wPy7RodLW2N5z7Wr+qbyp2hsxS1t0Eb5n/EqnlS1Hn+4bWLzyCK+IfsNEiqLQxP7X7g4 BSFWqpdOeGGOAHzm7auu73+d+eNDll/h4UiSt8TE5yDDFfjODS4kVfQqw2tBsRGrGROK 1vYN0wqhOMohkw8ssNlQuBNHrvKszcIixYhJ+gSafzp67Cq+r1oZWUT/ixLt+XUGktgi kMYYJUqWpA3wn6U2Rs1+1DqPFrewALGDRoRhpKIA2bH/2wWtNAYx5pV+vstRxugX1Ec7 GNyA== X-Forwarded-Encrypted: i=1; AJvYcCWHQAkEyLb/qlNeu7u1Z4NEdTbK0ztl1zNdeo6FLMykThefwT3i5VQUqBJE6I/1t+8IfG8MoYm2mA==@kvack.org X-Gm-Message-State: AOJu0Yy4uU5R7csizIk8iJdXHkfizpmsaxptoMHEoNbI4z5GHejPOUol B36yxin8C3drHuFLSrIlr81xCHkjY3+WYnV4lWWmh8WdFKT/rs65q6BWRn1osR7F/JetQgfjklw jRA5g4hLvQZWNPnHFKgeMwslKLyA= X-Gm-Gg: ASbGncuyF3QM4w50gHxJKCWuZXsQb1o1sCgjhU7sND/EcqwyU+OXz2/bF0wR4mje7tj IOTnNlUUmABYKfzH61Tq2TaFRS3wmBK2HU+Ut7PFUuMBgQAEY3VMP7KNQnwtzjTvzol/KSjNJbJ Y+6LwLWwNsG6oCD2sV8yZatFA= X-Google-Smtp-Source: AGHT+IEHwZwvERM6glWbYYwwzYCetfMHvG7kmqhssfc8GIXRgzL7p4OSea/eLcMf7tOLmQquK2cEHkkUW6DbI/qKOVg= X-Received: by 2002:a05:6122:2b47:b0:529:1a6a:cd48 with SMTP id 71dfb90a1353d-5291a6b07bemr170223e0c.6.1744857811522; Wed, 16 Apr 2025 19:43:31 -0700 (PDT) MIME-Version: 1.0 References: <20250412085852.48524-1-21cnbao@gmail.com> <34c54df6-9a7c-475d-9b91-0f8acb118231@redhat.com> <6259cc1d-93a8-4293-9009-a6119166f023@redhat.com> <20250416141531.GD741145@cmpxchg.org> <239cfe47-9826-402b-8008-de707faa160e@redhat.com> <20250416181835.GA779666@cmpxchg.org> <20250416235849.GA780688@cmpxchg.org> In-Reply-To: <20250416235849.GA780688@cmpxchg.org> From: Barry Song <21cnbao@gmail.com> Date: Thu, 17 Apr 2025 10:43:20 +0800 X-Gm-Features: ATxdqUEl8W05zT5OxxPD2alBle_1_ftAsTtwTrAsPphv_p55QZdh8rSZJeOtuLE Message-ID: Subject: Re: [RFC PATCH] mm: don't promote exclusive file folios of dying processes To: Johannes Weiner Cc: David Hildenbrand , akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Barry Song , Baolin Wang , Matthew Wilcox , Oscar Salvador , Ryan Roberts , Zi Yan Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: ik3gtuq19k3xsrj87c814ir5epaykca8 X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 947CA180010 X-Rspam-User: X-HE-Tag: 1744857812-431094 X-HE-Meta: U2FsdGVkX1/LszD8jSHb5JcKXLU/05Z+mkWLC5Mq+o/0lJMY1pjW4G6WusCbKdtpzV9b054hOPdszmTyJTHEoTZpSIbX7IWk+bFf8aSJxZQODSN9e1gU4qdXNQOFE113wfSihMLELd04O/1G6kXryMmBLoYpb09iypJjhslpHzUawyNzjH+AaPDRxZIcFLpViKNPhAPOn7LGpnF0iY4zDsfq6fDuhxdVf9Ppbt+ln7u5HBtC9SYX6YN4BTZAr6pnLdctUlfFU7Rxig1zTu4Hd98PWybMgb2u1fXT4QSAmkOr+zBHNLW/t1Lgot32AwA6TcYxzb0qIRXLJy6/bcTKGvK+2n8SmTG3qtgGAOT8d975cduCROhaRLAdJbT2scuqHN+VqEvktAVYN3bos8Pg9D/u3dxmbJUQZkejneRm5qWxcEkZDAlhqDWQhusAB3Az6vlFfjXNY4NO3tVZPL3fNIlzTtxWEY5j2qsNiy6tO87yzs4Lu5MgDrgZB6aBCsOY7xh3IeT/UYOpOfiLUO4zxaOxIiAJ0Mwbr4u9GxKO3kstyF4sklQz23g61c1BXJHq0XrifpbbSwQuF8EOCy2l4nCkUTNbzZ3rBNy+CC45Lap8Zz+4SWjKlmJlKZcZ5/L42WLi+lHXJQaYtxxkEOJtrguBBzrnDntlA0A4NHYnHz4F2iQt5MTEGjKtz6gbY5Gd0Q/6LcITzv0yoadLrqDBrhibDfWOUX/n/M6wJNYOYinBl3APgjD2VtDBczc7DBTfEdBgX+w4d6VjVpy14LOcHqMxUrGPS/NzYcOrtgq/feZ2UR4hm7xnuPb1VrF+gk/ENhf34ldAcg4RBxKX27Ckvk1mO5bwbaQw30263RCyDMcB6cV5Qu+H11Zr5K4CTymwwxilqe3eJngVMp0EyOyec5UxU0aU4dHt5nh6v9+tOTeMhJXTk1nU6c9A+SxAMwYy47mGmU5O9HyGzu4l9QD 759oeKph tdX+lJwkffKd9OmmxcrwzYTGU01ztJhHyxMHmvWM6FjU655wvde25XL8239uFFt+0Wq3BQzCSfYIZO3+SDZx4s2Nk5l8gNickEqMPNfjUCNICR3NRvuU30wNIefJZ3F1MCocm895Cm8yDfzdvIS3ml+qVWyZP+TXVXuOBCOs3gzVwxoElWr6/XPl7cplsmfFYkmr4peMv4co7NwqspjhIQO412+ykz3SDp7nkjex7l2eKk+/EFMge1OMmguAeO9zcPZgeJn/HiNyRzqZyTm/sC8X2gus1OVbfGcE1BJBxpqeheWX6DtKPXGoPAznq60e7Nn/OBoEnzm9lFKNMpadyANcO7jXyga8Pvz9ls2LEZuOeLAjn9iCixCcqt1P1aTJA7fMe X-Bogosity: Ham, tests=bogofilter, spamicity=0.018667, 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, Apr 17, 2025 at 7:58=E2=80=AFAM Johannes Weiner wrote: > > On Thu, Apr 17, 2025 at 05:54:57AM +0800, Barry Song wrote: > > On Thu, Apr 17, 2025 at 2:18=E2=80=AFAM Johannes Weiner wrote: > > > Right, I'm more broadly objecting to the patch and its premise, but > > > thought the exclusive filtering would at least mitigate its downsides > > > somewhat. You raise good points that it's not as clear cut. > > > > > > IMO this is too subtle and unpredictable for everybody else. The > > > kernel can't see the future, but access locality and recent use is a > > > proven predictor. We generally don't discard access information, > > > unless the user asks us to, and that's what the madvise calls are for= . > > > > David pointed out some exceptions - the recency of dying processes migh= t > > still be useful to new processes, particularly in cases like: > > > > while true; do app; done > > > > Here, 'app' is repeatedly restarted but always maintains a single runni= ng > > instance. I agree this seems correct. > > > > However, we can also find many cases where a dying process means its fo= lios > > instantly become cold. For example: > > Of course, there are many of them. Just like any access could be the > last one to that page for the next hour. But you don't know which ones > they are. Just like you don't know if I'm shutting down firefox > because that's enough internet for one day, or if I'm just restarting > it to clear out the 107 tabs I've lost track off. Typically, we focus on scenarios where multiple applications switch seamlessly=E2=80=94for instance, on a phone, when transitioning between different apps. The smoothness of these transitions matters most, Immediately restarting a just-terminated app isn't problematic since its memory footprint often persists before being reclaimed. > > > I agree that "access locality and recent use" is generally a good heuri= stic, > > but it must have some correlation (strong or weak) with the process lif= ecycle. > > I don't agree. It's a cache shared between past, present and future > processes. The lifecycle of an individual processes is not saying much. > > Unless you know something about userspace, and the exact data at hand, > that the kernel doesn't, which is why the Android usecase of MADV_COLD > or PAGEOUT for background apps makes sense to me, but generally tying > it to a process death does not. I agree that MADV_COLD or PAGEOUT makes sense for background apps, but I still believe process death is somewhat underestimated by you :-) In Android, process death is actually a strong signal that an app is inactive = and consuming much memory=E2=80=94leading to its termination by either userspac= e or the kernel's OOM mechanism. We actually took a more aggressive approach by implementing a hook to demot= e exclusive folios of dying apps, which yielded good results=E2=80=94reducing= kswapd overhead, refaults, and thrashing. Of course, it is even much more controve= rsial than this patch. While I acknowledge that counter-examples to my described pattern can alway= s be found, our observations clearly show that process death is a big event -= far from being just a trivial unmap operation. Anyway, not trying to push the patch as obviously it seems quite hard :-) Thanks Barry