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 AF035C433F5 for ; Tue, 18 Jan 2022 09:36:05 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2B9586B0072; Tue, 18 Jan 2022 04:36:05 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 267FA6B0073; Tue, 18 Jan 2022 04:36:05 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 130526B0074; Tue, 18 Jan 2022 04:36:05 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0232.hostedemail.com [216.40.44.232]) by kanga.kvack.org (Postfix) with ESMTP id 041596B0072 for ; Tue, 18 Jan 2022 04:36:05 -0500 (EST) Received: from smtpin10.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 78BE71814C3DC for ; Tue, 18 Jan 2022 09:36:04 +0000 (UTC) X-FDA: 79042901448.10.70CA8D0 Received: from my.chaos-reins.com (my.chaos-reins.com [104.248.178.247]) by imf09.hostedemail.com (Postfix) with ESMTP id 8FDE8140004 for ; Tue, 18 Jan 2022 09:36:03 +0000 (UTC) Received: (Haraka outbound); Tue, 18 Jan 2022 09:36:01 +0000 Received: from m.chaos-reins.com (21d594ba-beef-4400-bc88-b496d6dacd5a.cloudron [172.18.16.1]) by my.chaos-reins.com (Haraka/2.8.28) with ESMTPA id 8630A604-7CDC-4F56-BC02-9865974B8D06.1 envelope-from (authenticated bits=0); Tue, 18 Jan 2022 09:36:01 +0000 MIME-Version: 1.0 Date: Tue, 18 Jan 2022 09:36:01 +0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: RainLoop/1.16.0 From: "Donald Carr" Message-ID: Subject: Re: [PATCH v6 0/9] Multigenerational LRU Framework To: "Yu Zhao" Cc: "Andi Kleen" , "Catalin Marinas" , "Dave Hansen" , "Hillf Danton" , "Jens Axboe" , "Jesse Barnes" , "Johannes Weiner" , "Jonathan Corbet" , "Matthew Wilcox" , "Mel Gorman" , "Michael Larabel" , "Michal Hocko" , "Rik van Riel" , "Vlastimil Babka" , "Will Deacon" , "Ying Huang" , linux-arm-kernel@lists.infradead.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, page-reclaim@google.com, x86@kernel.org, "Andrew Morton" , "Linus Torvalds" In-Reply-To: References: <20220104202227.2903605-1-yuzhao@google.com> DKIM-Signature: v=1;a=rsa-sha256;bh=hOtzxRssqC3l7oqL8Wf80/oCWxDs7JXspEQpiCwzMik=;c=relaxed/simple;d=chaos-reins.com;h=from:subject:date:message-id:to:cc:mime-version;s=cloudron;b=IgaPi/pt7BRp7bjlfgUvPiJN7/YwMQCMwsmNETelA7tikFfLy570SUa2bNHmc4quqjevtpMhwUDXzURBvYqJNzY1ROqcKc2c6ZLQ04ELbm4JAkFFawva0U7U81kmDAYKFrN4lAY/5PPvwisV1HrpK4vOvwuSe45R9CPeWA44Hpw= X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 8FDE8140004 X-Stat-Signature: bpaegmnmheoacrntoqd7rhmuc4if4fx3 Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=chaos-reins.com header.s=cloudron header.b="IgaPi/pt"; spf=pass (imf09.hostedemail.com: domain of d@chaos-reins.com designates 104.248.178.247 as permitted sender) smtp.mailfrom=d@chaos-reins.com; dmarc=pass (policy=reject) header.from=chaos-reins.com X-HE-Tag: 1642498563-184083 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: January 18, 2022 1:21 AM, "Yu Zhao" wrote: > On Tue, Jan 11, 2022 at 01:41:22AM -0700, Yu Zhao wrote: >=20 >>=20On Tue, Jan 04, 2022 at 01:30:00PM -0700, Yu Zhao wrote: >> On Tue, Jan 04, 2022 at 01:22:19PM -0700, Yu Zhao wrote: >>> TLDR >>> =3D=3D=3D=3D >>> The current page reclaim is too expensive in terms of CPU usage and i= t >>> often makes poor choices about what to evict. This patchset offers an >>> alternative solution that is performant, versatile and >>> straightforward. >>=20 >>=20 >>=20 >>>=20Summery >>> =3D=3D=3D=3D=3D=3D=3D >>> The facts are: >>> 1. The independent lab results and the real-world applications >>> indicate substantial improvements; there are no known regressions. >>> 2. Thrashing prevention, working set estimation and proactive reclaim >>> work out of the box; there are no equivalent solutions. >>> 3. There is a lot of new code; nobody has demonstrated smaller change= s >>> with similar effects. >>>=20 >>>=20Our options, accordingly, are: >>> 1. Given the amount of evidence, the reported improvements will likel= y >>> materialize for a wide range of workloads. >>> 2. Gauging the interest from the past discussions [14][15][16], the >>> new features will likely be put to use for both personal computers >>> and data centers. >>> 3. Based on Google's track record, the new code will likely be well >>> maintained in the long term. It'd be more difficult if not >>> impossible to achieve similar effects on top of the existing >>> design. >>=20 >>=20Hi Andrew, Linus, >>=20 >>=20Can you please take a look at this patchset and let me know if it's >> 5.17 material? >>=20 >>=20My goal is to get it merged asap so that users can reap the benefits >> and I can push the sequels. Please examine the data provided -- I >> think the unprecedented coverage and the magnitude of the improvements >> warrant a green light. >=20 >=20My gratitude to Donald who has been helping test MGLRU since v2: >=20 >=20Donald Carr (d@chaos-reins.com) >=20 >=20Founder of Chaos Reins (http://chaos-reins.com), an SF based > consultancy company specializing in designing/creating embedded > Linux appliances. Tested-by: Donald Carr > Can you please provide your Tested-by tags? This will ensure the credit > for your contributions. >=20 >=20Thanks!