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 X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 72C33C433DB for ; Wed, 10 Feb 2021 09:56:22 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 8F4BE64E37 for ; Wed, 10 Feb 2021 09:56:20 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8F4BE64E37 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=sina.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id E9BC36B0006; Wed, 10 Feb 2021 04:56:19 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E4B476B006C; Wed, 10 Feb 2021 04:56:19 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D62AB6B006E; Wed, 10 Feb 2021 04:56:19 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0034.hostedemail.com [216.40.44.34]) by kanga.kvack.org (Postfix) with ESMTP id BF8D56B0006 for ; Wed, 10 Feb 2021 04:56:19 -0500 (EST) Received: from smtpin05.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 91A038149 for ; Wed, 10 Feb 2021 09:56:19 +0000 (UTC) X-FDA: 77801902878.05.lake11_5105dc12760f Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin05.hostedemail.com (Postfix) with ESMTP id 79C26185DDCC5 for ; Wed, 10 Feb 2021 09:56:19 +0000 (UTC) X-HE-Tag: lake11_5105dc12760f X-Filterd-Recvd-Size: 2351 Received: from r3-25.sinamail.sina.com.cn (r3-25.sinamail.sina.com.cn [202.108.3.25]) by imf32.hostedemail.com (Postfix) with SMTP for ; Wed, 10 Feb 2021 09:56:14 +0000 (UTC) Received: from unknown (HELO localhost.localdomain)([114.246.224.195]) by sina.com (172.16.97.23) with ESMTP id 6023ADAF0000C001; Wed, 10 Feb 2021 17:56:01 +0800 (CST) X-Sender: hdanton@sina.com X-Auth-ID: hdanton@sina.com X-SMAIL-MID: 25271854919412 From: Hillf Danton To: Jesse Barnes Cc: Yu Zhao , linux-mm@kvack.org, Linux Kernel Mailing List Subject: Re: [page-reclaim] Augmented Page Reclaim Date: Wed, 10 Feb 2021 17:55:50 +0800 Message-Id: <20210210095550.15928-1-hdanton@sina.com> In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Bogosity: Ham, tests=bogofilter, spamicity=0.400082, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, 9 Feb 2021 13:32:58 -0800 Jesse Barnes wrote: > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Augmented Page Reclaim > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > We would like to share a work with you and see if there is enough > > interest to warrant a run for the mainline. This work is a part of > > result from a decade of research and experimentation in memory > > overcommit at Google: an augmented page reclaim that, in our > > experience, is performant, versatile and, more importantly, simple. >=20 > Per discussion on IRC, maybe some additional background would help. >=20 > In looking at browser workloads on Chrome OS, we found that reclaim was= : > 1) too expensive in terms of CPU usage > 2) often making poor decisions about what to reclaim Feel free to send a patchset to LKML/MM - it can speak for itself. >=20 > This work was mainly targeted toward improving those things, with an > eye toward interactive performance for browser workloads. >=20 > We have a few key tests we use for that, that measure tab switch times > and number of tab discards when under memory pressure, and this > approach significantly improves these (see Yu's data). >=20 > We do expect this approach will also be beneficial to cloud workloads, > and so are looking for people to try it out in their environments with > their favorite key tests or workloads. >=20 > Thanks, > Jesse