[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20250430145106.8ce79a05d35cec72aa02baa6@linux-foundation.org>
Date: Wed, 30 Apr 2025 14:51:06 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: Qun-Wei Lin <qun-wei.lin@...iatek.com>
Cc: Mike Rapoport <rppt@...nel.org>, Matthias Brugger
<matthias.bgg@...il.com>, AngeloGioacchino Del Regno
<angelogioacchino.delregno@...labora.com>, Nhat Pham <nphamcs@...il.com>,
Sergey Senozhatsky <senozhatsky@...omium.org>, Minchan Kim
<minchan@...nel.org>, <linux-mm@...ck.org>, <linux-kernel@...r.kernel.org>,
<linux-arm-kernel@...ts.infradead.org>,
<linux-mediatek@...ts.infradead.org>, Casper Li <casper.li@...iatek.com>,
Chinwen Chang <chinwen.chang@...iatek.com>, Andrew Yang
<andrew.yang@...iatek.com>, James Hsu <james.hsu@...iatek.com>, Barry Song
<21cnbao@...il.com>
Subject: Re: [PATCH] mm: Add Kcompressd for accelerated memory compression
On Wed, 30 Apr 2025 16:26:41 +0800 Qun-Wei Lin <qun-wei.lin@...iatek.com> wrote:
> This patch series introduces a new mechanism called kcompressd to
> improve the efficiency of memory reclaiming in the operating system.
>
> Problem:
> In the current system, the kswapd thread is responsible for both scanning
> the LRU pages and handling memory compression tasks (such as those
> involving ZSWAP/ZRAM, if enabled). This combined responsibility can lead
> to significant performance bottlenecks, especially under high memory
> pressure. The kswapd thread becomes a single point of contention, causing
> delays in memory reclaiming and overall system performance degradation.
>
> Solution:
> Introduced kcompressd to handle asynchronous compression during memory
> reclaim, improving efficiency by offloading compression tasks from
> kswapd. This allows kswapd to focus on its primary task of page reclaim
> without being burdened by the additional overhead of compression.
>
> In our handheld devices, we found that applying this mechanism under high
> memory pressure scenarios can increase the rate of pgsteal_anon per second
> by over 260% compared to the situation with only kswapd. Additionally, we
> observed a reduction of over 50% in page allocation stall occurrences,
> further demonstrating the effectiveness of kcompressd in alleviating memory
> pressure and improving system responsiveness.
It's a significant change and I'm thinking that broader performance
testing across a broader range of machines is needed before we can
confidently upstream such a change.
Also, it's presumably a small net loss on single-CPU machines (do these
exist any more?). Is it hard to disable this feature on such machines?
>
> +static bool swap_sched_async_compress(struct folio *folio)
> +{
> + struct swap_info_struct *sis = swp_swap_info(folio->swap);
> + int nid = numa_node_id();
> + pg_data_t *pgdat = NODE_DATA(nid);
> +
> + if (unlikely(!pgdat->kcompressd))
> + return false;
> +
> + if (!current_is_kswapd())
> + return false;
> +
> + if (!folio_test_anon(folio))
> + return false;
Are you sure the above three tests are really needed?
Powered by blists - more mailing lists