[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <68cf749a-4248-1250-6e6e-713649ec8578@baylibre.com>
Date: Thu, 22 Jun 2023 09:39:19 +0200
From: Alexandre Mergnat <amergnat@...libre.com>
To: Sandeep Dhavale <dhavale@...gle.com>, Gao Xiang <xiang@...nel.org>,
Chao Yu <chao@...nel.org>, Yue Hu <huyue2@...lpad.com>,
Jeffle Xu <jefflexu@...ux.alibaba.com>,
Matthias Brugger <matthias.bgg@...il.com>,
AngeloGioacchino Del Regno
<angelogioacchino.delregno@...labora.com>
Cc: Will Shiu <Will.Shiu@...iatek.com>, kernel-team@...roid.com,
linux-erofs@...ts.ozlabs.org, linux-kernel@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org,
linux-mediatek@...ts.infradead.org
Subject: Re: [PATCH v1] erofs: Fix detection of atomic context
On 22/06/2023 00:08, Sandeep Dhavale wrote:
> Current check for atomic context is not sufficient as
> z_erofs_decompressqueue_endio can be called under rcu lock
> from blk_mq_flush_plug_list(). See the stacktrace [1]
>
> In such case we should hand off the decompression work for async
> processing rather than trying to do sync decompression in current
> context. Patch fixes the detection by checking for
> rcu_read_lock_any_held() and while at it use more appropriate
> !in_task() check than in_atomic().
>
> Background: Historically erofs would always schedule a kworker for
> decompression which would incur the scheduling cost regardless of
> the context. But z_erofs_decompressqueue_endio() may not always
> be in atomic context and we could actually benefit from doing the
> decompression in z_erofs_decompressqueue_endio() if we are in
> thread context, for example when running with dm-verity.
> This optimization was later added in patch [2] which has shown
> improvement in performance benchmarks.
Reviewed-by: Alexandre Mergnat <amergnat@...libre.com>
--
Regards,
Alexandre
Powered by blists - more mailing lists