[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <z22c2qgw2al73yij2ml2hlle2p24twgpmz4jemfqhjoiekc65f@pvap7olsolfp>
Date: Wed, 7 Jan 2026 19:14:54 +0900
From: Sergey Senozhatsky <senozhatsky@...omium.org>
To: zhangdongdong <zhangdongdong925@...a.com>
Cc: Sergey Senozhatsky <senozhatsky@...omium.org>,
Andrew Morton <akpm@...ux-foundation.org>, Richard Chang <richardycc@...gle.com>,
Minchan Kim <minchan@...nel.org>, Brian Geffon <bgeffon@...gle.com>,
David Stevens <stevensd@...gle.com>, linux-kernel@...r.kernel.org, linux-mm@...ck.org,
linux-block@...r.kernel.org, Minchan Kim <minchan@...gle.com>
Subject: Re: [PATCHv2 1/7] zram: introduce compressed data writeback
On (26/01/07 15:28), zhangdongdong wrote:
> Hi,Sergey
>
> Yes, we have tried high priority workqueues. In fact, our current
> implementation already uses a dedicated workqueue created with
> WQ_HIGHPRI and marked as UNBOUND, which handles the read/decompression
> path for swap-in.
>
> Below is a simplified snippet of the queue we are currently using:
>
> zgroup_read_wq = alloc_workqueue("zgroup_read",
> WQ_HIGHPRI | WQ_UNBOUND, 0);
>
> static int zgroup_submit_zio_async(struct zgroup_io *zio,
> struct zram_group *zgroup)
> {
> struct zgroup_req req = {
> .zio = zio,
> };
>
zgroup... That certainly looks like a lot of downstream code ;)
Do you use any strategies for writeback? Compressed writeback
is supposed to be used for apps for which latency is not critical
or sensitive, because of on-demand decompression costs.
Powered by blists - more mailing lists