Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <YBkT6175GmMWBvw3@google.com>
In-Reply-To: <YBkT6175GmMWBvw3@google.com>
From:   Jesse Barnes <jsbarnes@google.com>
Date:   Tue, 9 Feb 2021 13:32:58 -0800
Message-ID: <CAJmaN=miDwb4CvVDmLS4aBKsNOVp9XiDKB1Dp3s6cfrq4yXiQQ@mail.gmail.com>
Subject: Re: [page-reclaim] Augmented Page Reclaim
To:     Yu Zhao <yuzhao@google.com>, Sonny Rao <sonnyrao@google.com>,
        Jann Horn <jannh@google.com>,
        Matthew Wilcox <willy@infradead.org>
Cc:     linux-mm@kvack.org,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        page-reclaim@google.com
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

> ======================
> Augmented Page Reclaim
> ======================
> 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.

Per discussion on IRC, maybe some additional background would help.

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

This work was mainly targeted toward improving those things, with an
eye toward interactive performance for browser workloads.

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).

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.

Thanks,
Jesse