[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <761a2899-6fd9-4bfe-aeaf-23bce0baa0f1@redhat.com>
Date: Tue, 5 Aug 2025 12:47:36 +0200
From: David Hildenbrand <david@...hat.com>
To: SeongJae Park <sj@...nel.org>
Cc: "Liam R. Howlett" <Liam.Howlett@...cle.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Chengming Zhou <chengming.zhou@...ux.dev>,
Johannes Weiner <hannes@...xchg.org>, Jonathan Corbet <corbet@....net>,
Lorenzo Stoakes <lorenzo.stoakes@...cle.com>, Michal Hocko
<mhocko@...e.com>, Mike Rapoport <rppt@...nel.org>,
Nhat Pham <nphamcs@...il.com>, Suren Baghdasaryan <surenb@...gle.com>,
Vlastimil Babka <vbabka@...e.cz>, Yosry Ahmed <yosry.ahmed@...ux.dev>,
kernel-team@...a.com, linux-doc@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-mm@...ck.org,
Takero Funaki <flintglass@...il.com>
Subject: Re: [RFC PATCH v2] mm/zswap: store <PAGE_SIZE compression failed page
as-is
On 05.08.25 02:29, SeongJae Park wrote:
> When zswap writeback is enabled and it fails compressing a given page,
> the page is swapped out to the backing swap device. This behavior
> breaks the zswap's writeback LRU order, and hence users can experience
> unexpected latency spikes. If the page is compressed without failure,
> but results in a size of PAGE_SIZE, the LRU order is kept, but the
> decompression overhead for loading the page back on the later access is
> unnecessary.
>
> Keep the LRU order and optimize unnecessary decompression overheads in
> the cases, by storing the original content in zpool as-is.
Does this have any effect on the movability of the given page? IOW, does
page migration etc. still work when we store an ordinary page of an
shmem/anon folio here?
--
Cheers,
David / dhildenb
Powered by blists - more mailing lists