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 7D555C433F5 for ; Wed, 12 Jan 2022 16:18:05 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 13D7E6B0195; Wed, 12 Jan 2022 11:18:05 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 0EDC16B0196; Wed, 12 Jan 2022 11:18:05 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EA8566B0197; Wed, 12 Jan 2022 11:18:04 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0067.hostedemail.com [216.40.44.67]) by kanga.kvack.org (Postfix) with ESMTP id C05576B0195 for ; Wed, 12 Jan 2022 11:18:04 -0500 (EST) Received: from smtpin09.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 58E7795197 for ; Wed, 12 Jan 2022 16:18:04 +0000 (UTC) X-FDA: 79022141688.09.0F98A9D Received: from mail-io1-f47.google.com (mail-io1-f47.google.com [209.85.166.47]) by imf16.hostedemail.com (Postfix) with ESMTP id D5646180019 for ; Wed, 12 Jan 2022 16:18:03 +0000 (UTC) Received: by mail-io1-f47.google.com with SMTP id o7so4337598ioo.9 for ; Wed, 12 Jan 2022 08:18:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtu.edu; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=uX4CuZrEDPoEI3mLrH+dV7WoOJjqJH28sJzHNN8i4Kw=; b=Fcxt+ZbN0RQY4bhHKsko98bBv13yh8QaWOnpLDvCNErkioyxd2Yhm9g+Vnu9MOjXYq WNx6gLSttZxsyQNQ8ir1/WTQNoG79jJagEXS5VqD0mmgqCMEuOhHw4VBfPb+D7fM0aBM KKUUuK8GIXnPCdXqpOd8ulhcbLkSTLKFdWaH/18RuXucF2Xg9hc3F3jJ3sGIA+SqnfwD ons50klJDWoxxQTFVOOK5U2o/6HmsC7oTF6+1Qh1Xx8jc5lHc2TKHb9tKmahMTfDkZvl svowg8tMGv+noca2q2cS8zObQQyE8LASFHUkHl0I3mdom/IsIJbSWATPBrcVhn3u38/D iYrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=uX4CuZrEDPoEI3mLrH+dV7WoOJjqJH28sJzHNN8i4Kw=; b=MOPlu1+MQEW9Bizi1jUY/bJIGwdYPcAPLa25evYEVkOGnDYrzV//EwP+A3L8cwFz+J SqjI42sSf0bMM1scSzLQJikSTm+QBvqwjYZbar53uGGplkCiVgRqTUuJ7vF2NGAyuqsm EjZ7H5uGaMT+ndwh9T/L/fBnZFItYXyvDrjeZv5BFG/6MQMVh4radoHXKTiB59LyvLtp lR+2c4vn+iiyrlV/N+L7CKyu7JKAPR5FDoEAjcn2iouDpspCaTPQof6J3RX5O6NMGcI7 7DGFkVRa48hhWNTXbpn6cnMj2oQmaerotKE/9DHtdT5qcI8LDKbZXnL9bbe+98erd2u0 Lqag== X-Gm-Message-State: AOAM530tdK1OmG1wrekvxfYPErzKmzbAbXn9R/N5RrVE2d8+hrENS0mD i1h9SQd9dOhfvUvP6vnCoWXR5pJDKgRRnxYdplg= X-Google-Smtp-Source: ABdhPJzcRCaOOrl3B/HFpMuy7suaqGfN1oqRrHdxFE0vp3nmID3F3zPLkZ61+I9MoSntOM5aocU95V1q4wzn1yblyW4= X-Received: by 2002:a05:6638:72e:: with SMTP id j14mr224858jad.246.1642004282861; Wed, 12 Jan 2022 08:18:02 -0800 (PST) MIME-Version: 1.0 References: <20220104202227.2903605-1-yuzhao@google.com> In-Reply-To: From: Daniel Byrne Date: Wed, 12 Jan 2022 11:17:50 -0500 Message-ID: Subject: Re: [PATCH v6 0/9] Multigenerational LRU Framework To: Sofia Trinh Cc: Yu Zhao , Alexandre Frade , Brian Geffon , Daniel Byrne , =?UTF-8?Q?Holger_Hoffst=C3=A4tte?= , Jan Alexander Steffens , Shuang Zhai , Steven Barrett , Suleiman Souhlal , 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 Content-Type: multipart/alternative; boundary="000000000000ffecb705d564e999" X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: D5646180019 X-Stat-Signature: pn5fbnrb8phswi7r6nwjhakk8o3wcton Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=mtu.edu header.s=google header.b=Fcxt+ZbN; spf=pass (imf16.hostedemail.com: domain of byrnedj12@gmail.com designates 209.85.166.47 as permitted sender) smtp.mailfrom=byrnedj12@gmail.com; dmarc=pass (policy=none) header.from=mtu.edu X-HE-Tag: 1642004283-529290 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: --000000000000ffecb705d564e999 Content-Type: text/plain; charset="UTF-8" Tested-by: Daniel Byrne with memcached allocating ~100GB of byte-addressable Optante, performance improvement in terms of throughput (measured as queries per second) was about 10% for a series of workloads. On Wed, Jan 12, 2022 at 1:07 AM Sofia Trinh wrote: > On Tue, Jan 11, 2022 at 12:41 AM Yu Zhao wrote: > > > > On 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 > > > > ==== > > > > The current page reclaim is too expensive in terms of CPU usage and > it > > > > often makes poor choices about what to evict. This patchset offers an > > > > alternative solution that is performant, versatile and > > > > straightforward. > > > > > > > > > > > > > Summery > > > > ======= > > > > 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 > changes > > > > with similar effects. > > > > > > > > Our options, accordingly, are: > > > > 1. Given the amount of evidence, the reported improvements will > likely > > > > 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. > > > > > > Hi Andrew, Linus, > > > > > > Can you please take a look at this patchset and let me know if it's > > > 5.17 material? > > > > > > My 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. > > > > Downstream kernel maintainers who have been carrying MGLRU for more than > > 3 versions, can you please provide your Acked-by tags? > > > > Having this patchset in the mainline will make your job easier :) > > > > Alexandre - the XanMod Kernel maintainer > > https://xanmod.org > > > > Brian - the Chrome OS kernel memory maintainer > > https://www.chromium.org > > > > Jan - the Arch Linux Zen kernel maintainer > > https://archlinux.org > > > > Steven - the Liquorix kernel maintainer > > https://liquorix.net > > > > Suleiman - the ARCVM (Android downstream) kernel memory maintainer > > > https://chromium.googlesource.com/chromiumos/third_party/kernel > > > > Also my gratitude to those who have helped test MGLRU: > > > > Daniel - researcher at Michigan Tech > > benchmarked memcached > > > > Holger - who has been testing/patching/contributing to various > > subsystems since ~2008 > > > > Shuang - researcher at University of Rochester > > benchmarked fio and provided a report > > > > Sofia - EDI https://www.edi.works > > benchmarked the top eight memory hogs and provided reports > > Tested-by: Sofia Trinh > -- Daniel Byrne --000000000000ffecb705d564e999 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Tested-by: Daniel Byrne <djbyrne@mtu.edu> with memcached allocating ~100GB of byte-ad= dressable Optante, performance improvement in terms of throughput (measured= as queries per second) was about 10% for a series of workloads.
=

= On Wed, Jan 12, 2022 at 1:07 AM Sofia Trinh <sofia.trinh@edi.works> w= rote:
On Tue, Ja= n 11, 2022 at 12:41 AM Yu Zhao <yuzhao@google.com> wrote:
>
> On 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 us= age and it
> > > often makes poor choices about what to evict. This patchset = offers an
> > > alternative solution that is performant, versatile and
> > > straightforward.
> >
> > <snipped>
> >
> > > Summery
> > > =3D=3D=3D=3D=3D=3D=3D
> > > The facts are:
> > > 1. The independent lab results and the real-world applicatio= ns
> > >=C2=A0 =C2=A0 indicate substantial improvements; there are no= known regressions.
> > > 2. Thrashing prevention, working set estimation and proactiv= e reclaim
> > >=C2=A0 =C2=A0 work out of the box; there are no equivalent so= lutions.
> > > 3. There is a lot of new code; nobody has demonstrated small= er changes
> > >=C2=A0 =C2=A0 with similar effects.
> > >
> > > Our options, accordingly, are:
> > > 1. Given the amount of evidence, the reported improvements w= ill likely
> > >=C2=A0 =C2=A0 materialize for a wide range of workloads.
> > > 2. Gauging the interest from the past discussions [14][15][1= 6], the
> > >=C2=A0 =C2=A0 new features will likely be put to use for both= personal computers
> > >=C2=A0 =C2=A0 and data centers.
> > > 3. Based on Google's track record, the new code will lik= ely be well
> > >=C2=A0 =C2=A0 maintained in the long term. It'd be more d= ifficult if not
> > >=C2=A0 =C2=A0 impossible to achieve similar effects on top of= the existing
> > >=C2=A0 =C2=A0 design.
> >
> > Hi Andrew, Linus,
> >
> > Can you please take a look at this patchset and let me know if it= 's
> > 5.17 material?
> >
> > My goal is to get it merged asap so that users can reap the benef= its
> > and I can push the sequels. Please examine the data provided -- I=
> > think the unprecedented coverage and the magnitude of the improve= ments
> > warrant a green light.
>
> Downstream kernel maintainers who have been carrying MGLRU for more th= an
> 3 versions, can you please provide your Acked-by tags?
>
> Having this patchset in the mainline will make your job easier :)
>
>=C2=A0 =C2=A0 Alexandre - the XanMod Kernel maintainer
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://xanmod.org=
>
>=C2=A0 =C2=A0 Brian=C2=A0 =C2=A0 =C2=A0- the Chrome OS kernel memory ma= intainer
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.chro= mium.org
>
>=C2=A0 =C2=A0 Jan=C2=A0 =C2=A0 =C2=A0 =C2=A0- the Arch Linux Zen kernel= maintainer
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://archlinux.o= rg
>
>=C2=A0 =C2=A0 Steven=C2=A0 =C2=A0 - the Liquorix kernel maintainer
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://liquorix.net=
>
>=C2=A0 =C2=A0 Suleiman=C2=A0 - the ARCVM (Android downstream) kernel me= mory maintainer
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://chromium.googlesource.com/chromiumos/third_p= arty/kernel
>
> Also my gratitude to those who have helped test MGLRU:
>
>=C2=A0 =C2=A0 Daniel - researcher at Michigan Tech
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0benchmarked memcached >
>=C2=A0 =C2=A0 Holger - who has been testing/patching/contributing to va= rious
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0subsystems since ~2008<= br> >
>=C2=A0 =C2=A0 Shuang - researcher at University of Rochester
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0benchmarked fio and pro= vided a report
>
>=C2=A0 =C2=A0 Sofia=C2=A0 - EDI https://www.edi.works
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0benchmarked the top eig= ht memory hogs and provided reports

Tested-by: Sofia Trinh <sofia.trinh@edi.works>


--
Daniel B= yrne

--000000000000ffecb705d564e999--