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 2DE25C369AB for ; Tue, 15 Apr 2025 06:19:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 660982800CF; Tue, 15 Apr 2025 02:19:49 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5E7C72800C7; Tue, 15 Apr 2025 02:19:49 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 415FB2800CF; Tue, 15 Apr 2025 02:19:49 -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 145452800C7 for ; Tue, 15 Apr 2025 02:19:49 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 7F1F480F88 for ; Tue, 15 Apr 2025 06:19:50 +0000 (UTC) X-FDA: 83335277340.24.8DC17DD Received: from mail-lj1-f173.google.com (mail-lj1-f173.google.com [209.85.208.173]) by imf28.hostedemail.com (Postfix) with ESMTP id 7796EC000B for ; Tue, 15 Apr 2025 06:19:48 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=gRrOgmEQ; spf=pass (imf28.hostedemail.com: domain of ryncsn@gmail.com designates 209.85.208.173 as permitted sender) smtp.mailfrom=ryncsn@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=1744697988; 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=6Wv6OGD/mXBijI8bI4QMl+8zCCxYWngmJJ4GivvEdgo=; b=cYuC8R0uXgWVMoQUjF+H9YVVUCvceeLq9qrgLdOOb+3j9GQEFJ5+lmZg2UEyvot+xKUNfZ fcMMdE5w26XEWrqW4C2caRIDk6S73571zBYDpqgsOjqVTjypcUpbIMvCUWCHGKK0YLbstD 6TC3+vNiZ2T5f2DLBx5/xsmWF11aKOY= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=gRrOgmEQ; spf=pass (imf28.hostedemail.com: domain of ryncsn@gmail.com designates 209.85.208.173 as permitted sender) smtp.mailfrom=ryncsn@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1744697988; a=rsa-sha256; cv=none; b=76qGVjPGExPqW8rr6LCXjKjZ72ir96AVvILcPyGkGkQTZ5idHpBi3Wkc4fQ1m1BxGwglNR SCsSHqerrwbLihlpNp0azSNKsne9HquhGHM+ZilMWwPDrbY7B0fQqtD/04ItL/DL1nuDSc U5jvupecQk37KxnR5qgP9BfXeT4IcQg= Received: by mail-lj1-f173.google.com with SMTP id 38308e7fff4ca-31062172698so21976701fa.0 for ; Mon, 14 Apr 2025 23:19:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1744697986; x=1745302786; 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=6Wv6OGD/mXBijI8bI4QMl+8zCCxYWngmJJ4GivvEdgo=; b=gRrOgmEQs9PD+yhzk6F003s+Tfy9H+5wEK9qbEPSdsIJF66J2mk2nHgdMVb1wwfS/G 9letRcfEGHN+z7V+0kX44lTWPTJOel2C8FZo0yZBZWVwdx6hImJLxMDVA8LGujTWnFnQ jt1BpWTB8Vu4gzH3xhXNktqi9NEeutepW2JVpnErClVvN70R2HIgjc7Gx6BR24pdpLMl oDPS+Ik1zbJf972NZnoH4rb5V3VT1It/ynKoTCBr9rVrk0vyyPfw8UbjCzLDuhyfHlPl 1iVhb2CNBGi5InBBZzsO9AsAdqHsveQvANDMpQAyLxRBqzcvBIm/XcQoh0mshsvyZe7j q+6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1744697986; x=1745302786; 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=6Wv6OGD/mXBijI8bI4QMl+8zCCxYWngmJJ4GivvEdgo=; b=NLFP1aDYEf5t7fcguQgSUQWkuGK6Jeg/3SUrmGtkq7ttRR9Ep+TuJVqitQ3IdeIqO3 JHxeheQbE+YrTcZ/xX/ZryxCNuneIa3NtFcANxKy1fsZNIEOBBCNsK0Ddj4RawzK1gk3 i/5g25KFLcduFj1NAQSOiub0wUYa9kMnFETEfHNwy5wEQAI3bV+04hGySMl0HoEmXYhI uBWxeRYTte5L9p0mHhk+c01Hv6cV5B2cS4ObtpomwzpIahiC7lZ+4gKIL5tYjWe2r9vj 29+vDE+hcsxYhz3ubxAQ1q/LqIVtTKXmiytjdomtZ7k6D9emgaJinbEeUlpv2wTBIRBf 1MHw== X-Forwarded-Encrypted: i=1; AJvYcCUAN9fW0SeaLrS74vj5Albrz7VJgYN5JFoeDVOlAjPLE9fRr4HTRn5SQxkwk5+KafI3OYI7FYEbAw==@kvack.org X-Gm-Message-State: AOJu0YxRCxXirI4Z4DkR9Px2teaJFE6zqG0htvoZERXjE00B7815aGSi xKQODszyhz1p8vw5B6F8F26XY+JXiX85iWCJN9WUEvp6f3ujJWJ8+XcJKD7NDYpMEPyus0mPPeU BgQK58+UuHeqgNtzdqpWJr9TRFGk= X-Gm-Gg: ASbGncvV0DK/TLGbHIjqYSdsbKhCT12j3IGPV/VU9gaJoK2uN0YdYFEGs3i9wAA1dqR Zldg7hC2NQAssnDZ1Wf3qWx9VmXufQEb6PZi6Skaz7Fp/fp4Q3oY1rfNy+3H3snrjmp+YEgUhr2 ghSbK0w+cOokTbKftcRKSvvg== X-Google-Smtp-Source: AGHT+IGHSVaZAFez4uVGYYlGMTKYrqz407FNx7uyL5wqvWr1DNKiSA9rzLGe7ytSTGwFX8LR8jm4JMJ4fhomOl3fjmo= X-Received: by 2002:a2e:a549:0:b0:30c:460f:f56 with SMTP id 38308e7fff4ca-31049a1afc5mr44927281fa.20.1744697986177; Mon, 14 Apr 2025 23:19:46 -0700 (PDT) MIME-Version: 1.0 References: <20250415024532.26632-1-songmuchun@bytedance.com> In-Reply-To: <20250415024532.26632-1-songmuchun@bytedance.com> From: Kairui Song Date: Tue, 15 Apr 2025 14:19:29 +0800 X-Gm-Features: ATxdqUFIoo8leWhSgNKio3tny0lnfgXi7RhMYezcohewSU1OXRUyhi5BW1sJQeM Message-ID: Subject: Re: [PATCH RFC 00/28] Eliminate Dying Memory Cgroup To: Muchun Song Cc: hannes@cmpxchg.org, mhocko@kernel.org, roman.gushchin@linux.dev, shakeel.butt@linux.dev, muchun.song@linux.dev, akpm@linux-foundation.org, david@fromorbit.com, zhengqi.arch@bytedance.com, yosry.ahmed@linux.dev, nphamcs@gmail.com, chengming.zhou@linux.dev, linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, linux-mm@kvack.org, hamzamahfooz@linux.microsoft.com, apais@linux.microsoft.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 7796EC000B X-Stat-Signature: 8h1ioobfw3gyazuyx7hs3pjq8ooyzfke X-Rspam-User: X-Rspamd-Server: rspam12 X-HE-Tag: 1744697988-182660 X-HE-Meta: U2FsdGVkX1/B55wr9g7mBo85izY666sU8L3BTmwKUXgBpW6yIr5UK6lyDZs6eSPZNq8j6osyKbbI8+EdK2JGDj36+J97nbu44K1ln0tFd6WUZTf7GjHCS8VYQA/AQR1KYQizNR4Eh9+sze/9XXRaUWekj2Yf0f5BxHWUu3SofKJhMTLP/FididMOhfJgyYWkUjf7mvl//HeKEgl5alwA51USca7+Nk1Zl851ZhDby1E74Mb15O9qf8vs+rMRVnKV1n6OIGZflAAlk328oqLPtETGA6K5uH3iLKyj5FmKIJWKY7JNYCpK7cMwvw03tnqpX0XLXnOajjoUbd1w/h6HjeBaU6Samz+MZr2XLSGa6mkcbDyHoFaCoTa/adCrWYjZmICPkY2xpggDWdSZ4IXCJTecVo8QM7hClHdhwWIyiQAeggZ4PblR10w3P1h3oQDgMhiR9dj0gqvxBhRIVu0GjKiZ+f5qJlcvdlBa46XJyRxZU42ZYk+A+CDz4hmEzEXpTaPD4ENcR+wTynB6nZxq3jBUBIzKulFTwEIuhFOhHB8MMCfq+tduPv6VM7x9W/unroxVmKKJWGWGBsO2Js6U7aTPM+2fElIHVdKhsixpBx2/lBewIPbb+BEB01wa26yJmUMd2P4gTRK9/iNdwvM2kSQW7jj61hoqNMH3M8ekZA4Y2ic3DJrp5lMqpnQDDldwimix+wQhiD1INtjwl9pOVSAdOXQrV/9IOzPhkp0eVolVNEsnnyao849urAdeGK4FwDjlv6Lse1uFoUmyFK9EVkzFwJSKKAzeDdnLb9hjCtfQVkG4dtcfLsVaHr/gsFH3ca8+FlpAJukgxNha6tMjE8Sr4LtUQAO0HIC/Jx0YCymyrHVDr3T07CwtWOBPN8tFzeRQ7GheWRQDyfNnDkdC6z+jjYM59wIc4FSSqzJaLYng4kkCRfJs7tH1hJ+hSBIB1o5RvMJR55x1cVRKrRq 1dyk0sRr /mtspUGx1beRLdWWzDbGDPfZfwxJ/X7GhzMI6JglOSKHz+mkeTk4sQnFYywiNiEiCQQJlZlSNq3cV5Lvsdn+2xBYkHKZI/WmTYVa83jEs1ayT+wyy3mM3PTCByoc/COEImM27x6iwX3nox+SEV6K8TEUkn9wzLs7fTPLpQnwsXPHXfsg/W+1f+3xMZSjuDEBs0WJUQE56iTkKOOiT+WoLX5Z+zzzz2vURRQKU9LpMWDq9HWivSeV8W8HdHS8tuv9wW/v4WUeLNm1NfmwUwExF2ynqOj0NFOEKGY0AI+X85UhLcJyIhN3ka9gTb9sZQ8cxGOzuNkw59Te+fezHLhiSvZEyeIw0ISrNifhfuFtkNTiZ9nBupwZxUAmv2WPA1d58lp9n6dFSVYcTvI4vZZg/sqt9nu44tT277+hOgAtEAf4t4ZZnpBqVjJoq4l3iIjtDVlfQ 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: List-Subscribe: List-Unsubscribe: On Tue, Apr 15, 2025 at 10:46=E2=80=AFAM Muchun Song wrote: > > This patchset is based on v6.15-rc2. It functions correctly only when > CONFIG_LRU_GEN (Multi-Gen LRU) is disabled. Several issues were encounter= ed > during rebasing onto the latest code. For more details and assistance, re= fer > to the "Challenges" section. This is the reason for adding the RFC tag. > > ## Introduction > > This patchset is intended to transfer the LRU pages to the object cgroup > without holding a reference to the original memory cgroup in order to > address the issue of the dying memory cgroup. A consensus has already bee= n > reached regarding this approach recently [1]. > > ## Background > > The issue of a dying memory cgroup refers to a situation where a memory > cgroup is no longer being used by users, but memory (the metadata > associated with memory cgroups) remains allocated to it. This situation > may potentially result in memory leaks or inefficiencies in memory > reclamation and has persisted as an issue for several years. Any memory > allocation that endures longer than the lifespan (from the users' > perspective) of a memory cgroup can lead to the issue of dying memory > cgroup. We have exerted greater efforts to tackle this problem by > introducing the infrastructure of object cgroup [2]. > > Presently, numerous types of objects (slab objects, non-slab kernel > allocations, per-CPU objects) are charged to the object cgroup without > holding a reference to the original memory cgroup. The final allocations > for LRU pages (anonymous pages and file pages) are charged at allocation > time and continues to hold a reference to the original memory cgroup > until reclaimed. > > File pages are more complex than anonymous pages as they can be shared > among different memory cgroups and may persist beyond the lifespan of > the memory cgroup. The long-term pinning of file pages to memory cgroups > is a widespread issue that causes recurring problems in practical > scenarios [3]. File pages remain unreclaimed for extended periods. > Additionally, they are accessed by successive instances (second, third, > fourth, etc.) of the same job, which is restarted into a new cgroup each > time. As a result, unreclaimable dying memory cgroups accumulate, > leading to memory wastage and significantly reducing the efficiency > of page reclamation. > > ## Fundamentals > > A folio will no longer pin its corresponding memory cgroup. It is necessa= ry > to ensure that the memory cgroup or the lruvec associated with the memory > cgroup is not released when a user obtains a pointer to the memory cgroup > or lruvec returned by folio_memcg() or folio_lruvec(). Users are required > to hold the RCU read lock or acquire a reference to the memory cgroup > associated with the folio to prevent its release if they are not concerne= d > about the binding stability between the folio and its corresponding memor= y > cgroup. However, some users of folio_lruvec() (i.e., the lruvec lock) > desire a stable binding between the folio and its corresponding memory > cgroup. An approach is needed to ensure the stability of the binding whil= e > the lruvec lock is held, and to detect the situation of holding the > incorrect lruvec lock when there is a race condition during memory cgroup > reparenting. The following four steps are taken to achieve these goals. > > 1. The first step to be taken is to identify all users of both functions > (folio_memcg() and folio_lruvec()) who are not concerned about binding > stability and implement appropriate measures (such as holding a RCU re= ad > lock or temporarily obtaining a reference to the memory cgroup for a > brief period) to prevent the release of the memory cgroup. > > 2. Secondly, the following refactoring of folio_lruvec_lock() demonstrate= s > how to ensure the binding stability from the user's perspective of > folio_lruvec(). > > struct lruvec *folio_lruvec_lock(struct folio *folio) > { > struct lruvec *lruvec; > > rcu_read_lock(); > retry: > lruvec =3D folio_lruvec(folio); > spin_lock(&lruvec->lru_lock); > if (unlikely(lruvec_memcg(lruvec) !=3D folio_memcg(folio))) { > spin_unlock(&lruvec->lru_lock); > goto retry; > } > > return lruvec; > } > > From the perspective of memory cgroup removal, the entire reparenting > process (altering the binding relationship between folio and its memor= y > cgroup and moving the LRU lists to its parental memory cgroup) should = be > carried out under both the lruvec lock of the memory cgroup being remo= ved > and the lruvec lock of its parent. > > 3. Thirdly, another lock that requires the same approach is the split-que= ue > lock of THP. > > 4. Finally, transfer the LRU pages to the object cgroup without holding a > reference to the original memory cgroup. > Hi, Muchun, thanks for the patch. > ## Challenges > > In a non-MGLRU scenario, each lruvec of every memory cgroup comprises fou= r > LRU lists (i.e., two active lists for anonymous and file folios, and two > inactive lists for anonymous and file folios). Due to the symmetry of the > LRU lists, it is feasible to transfer the LRU lists from a memory cgroup > to its parent memory cgroup during the reparenting process. Symmetry of LRU lists doesn't mean symmetry 'hotness', it's totally possible that a child's active LRU is colder and should be evicted first before the parent's inactive LRU (might even be a common scenario for certain workloads). This only affects the performance not the correctness though, so not a big problem. So will it be easier to just assume dying cgroup's folios are colder? Simply move them to parent's LRU tail is OK. This will make the logic appliable for both active/inactive LRU and MGLRU. > > In a MGLRU scenario, each lruvec of every memory cgroup comprises at leas= t > 2 (MIN_NR_GENS) generations and at most 4 (MAX_NR_GENS) generations. > > 1. The first question is how to move the LRU lists from a memory cgroup t= o > its parent memory cgroup during the reparenting process. This is due t= o > the fact that the quantity of LRU lists (aka generations) may differ > between a child memory cgroup and its parent memory cgroup. > > 2. The second question is how to make the process of reparenting more > efficient, since each folio charged to a memory cgroup stores its > generation counter into its ->flags. And the generation counter may > differ between a child memory cgroup and its parent memory cgroup beca= use > the values of ->min_seq and ->max_seq are not identical. Should those > generation counters be updated correspondingly? I think you do have to iterate through the folios to set or clear their generation flags if you want to put the folio in the right gen. MGLRU does similar thing in inc_min_seq. MGLRU uses the gen flags to defer the actual LRU movement of folios, that's a very important optimization per my test. > > I am uncertain about how to handle them appropriately as I am not an > expert at MGLRU. I would appreciate it if you could offer some suggestion= s. > Moreover, if you are willing to directly provide your patches, I would be > glad to incorporate them into this patchset. If we just follow the above idea (move them to parent's tail), we can just keep the folio's tier info untouched here. For mapped file folios, they will still be promoted upon eviction if their access bit are set (rmap walk), and MGLRU's table walker might just promote them just fine. For unmapped file folios, if we just keep their tier info and add child's MGLRU tier PID counter back to the parent. Workingset protection of MGLRU should still work just fine. > > ## Compositions > > Patches 1-8 involve code refactoring and cleanup with the aim of > facilitating the transfer LRU folios to object cgroup infrastructures. > > Patches 9-10 aim to allocate the object cgroup for non-kmem scenarios, > enabling the ability that LRU folios could be charged to it and aligning > the behavior of object-cgroup-related APIs with that of the memory cgroup= . > > Patches 11-19 aim to prevent memory cgroup returned by folio_memcg() from > being released. > > Patches 20-23 aim to prevent lruvec returned by folio_lruvec() from being > released. > > Patches 24-25 implement the core mechanism to guarantee binding stability > between the folio and its corresponding memory cgroup while holding lruve= c > lock or split-queue lock of THP. > > Patches 26-27 are intended to transfer the LRU pages to the object cgroup > without holding a reference to the original memory cgroup in order to > address the issue of the dying memory cgroup. > > Patch 28 aims to add VM_WARN_ON_ONCE_FOLIO to LRU maintenance helpers to > ensure correct folio operations in the future. > > ## Effect > > Finally, it can be observed that the quantity of dying memory cgroups wil= l > not experience a significant increase if the following test script is > executed to reproduce the issue. > > ```bash > #!/bin/bash > > # Create a temporary file 'temp' filled with zero bytes > dd if=3D/dev/zero of=3Dtemp bs=3D4096 count=3D1 > > # Display memory-cgroup info from /proc/cgroups > cat /proc/cgroups | grep memory > > for i in {0..2000} > do > mkdir /sys/fs/cgroup/memory/test$i > echo $$ > /sys/fs/cgroup/memory/test$i/cgroup.procs > > # Append 'temp' file content to 'log' > cat temp >> log > > echo $$ > /sys/fs/cgroup/memory/cgroup.procs > > # Potentially create a dying memory cgroup > rmdir /sys/fs/cgroup/memory/test$i > done > > # Display memory-cgroup info after test > cat /proc/cgroups | grep memory > > rm -f temp log > ``` > > ## References > > [1] https://lore.kernel.org/linux-mm/Z6OkXXYDorPrBvEQ@hm-sls2/ > [2] https://lwn.net/Articles/895431/ > [3] https://github.com/systemd/systemd/pull/36827 How much overhead will it be? Objcj has some extra overhead, and we have some extra convention for retrieving memcg of a folio now, not sure if this will have an observable slow down. I'm still thinking if it be more feasible to just migrate (NOT that Cgroup V1 migrate, just set the folio's memcg to parent for dying cgroup and update the memcg charge) and iterate the folios on reparenting in a worker or something like that. There is already things like destruction workqueue and offline waitqueue. That way folios will still just point to a memcg, and seems would avoid a lot of complexity. > > Muchun Song (28): > mm: memcontrol: remove dead code of checking parent memory cgroup > mm: memcontrol: use folio_memcg_charged() to avoid potential rcu lock > holding > mm: workingset: use folio_lruvec() in workingset_refault() > mm: rename unlock_page_lruvec_irq and its variants > mm: thp: replace folio_memcg() with folio_memcg_charged() > mm: thp: introduce folio_split_queue_lock and its variants > mm: thp: use folio_batch to handle THP splitting in > deferred_split_scan() > mm: vmscan: refactor move_folios_to_lru() > mm: memcontrol: allocate object cgroup for non-kmem case > mm: memcontrol: return root object cgroup for root memory cgroup > mm: memcontrol: prevent memory cgroup release in > get_mem_cgroup_from_folio() > buffer: prevent memory cgroup release in folio_alloc_buffers() > writeback: prevent memory cgroup release in writeback module > mm: memcontrol: prevent memory cgroup release in > count_memcg_folio_events() > mm: page_io: prevent memory cgroup release in page_io module > mm: migrate: prevent memory cgroup release in folio_migrate_mapping() > mm: mglru: prevent memory cgroup release in mglru > mm: memcontrol: prevent memory cgroup release in > mem_cgroup_swap_full() > mm: workingset: prevent memory cgroup release in lru_gen_eviction() > mm: workingset: prevent lruvec release in workingset_refault() > mm: zswap: prevent lruvec release in zswap_folio_swapin() > mm: swap: prevent lruvec release in swap module > mm: workingset: prevent lruvec release in workingset_activation() > mm: memcontrol: prepare for reparenting LRU pages for lruvec lock > mm: thp: prepare for reparenting LRU pages for split queue lock > mm: memcontrol: introduce memcg_reparent_ops > mm: memcontrol: eliminate the problem of dying memory cgroup for LRU > folios > mm: lru: add VM_WARN_ON_ONCE_FOLIO to lru maintenance helpers > > fs/buffer.c | 4 +- > fs/fs-writeback.c | 22 +- > include/linux/memcontrol.h | 190 ++++++------ > include/linux/mm_inline.h | 6 + > include/trace/events/writeback.h | 3 + > mm/compaction.c | 43 ++- > mm/huge_memory.c | 218 +++++++++----- > mm/memcontrol-v1.c | 15 +- > mm/memcontrol.c | 476 +++++++++++++++++++------------ > mm/migrate.c | 2 + > mm/mlock.c | 2 +- > mm/page_io.c | 8 +- > mm/percpu.c | 2 +- > mm/shrinker.c | 6 +- > mm/swap.c | 22 +- > mm/vmscan.c | 73 ++--- > mm/workingset.c | 26 +- > mm/zswap.c | 2 + > 18 files changed, 696 insertions(+), 424 deletions(-) > > -- > 2.20.1 > >