mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Gao Xiang <hsiangkao@linux.alibaba.com>
To: Eric Biggers <ebiggers@kernel.org>
Cc: linux-erofs@lists.ozlabs.org, Chao Yu <chao@kernel.org>,
	Yue Hu <huyue2@coolpad.com>,
	Jeffle Xu <jefflexu@linux.alibaba.com>,
	Sandeep Dhavale <dhavale@google.com>,
	kernel-team@android.com, LKML <linux-kernel@vger.kernel.org>,
	Nathan Huckleberry <nhuck@google.com>
Subject: Re: [PATCH v5] erofs: add per-cpu threads for decompression as an option
Date: Fri, 24 Feb 2023 02:52:54 +0800	[thread overview]
Message-ID: <ca1e604a-92ba-023b-8896-dcad9413081d@linux.alibaba.com> (raw)
In-Reply-To: <Y/ewpGQkpWvOf7qh@gmail.com>

Hi Eric,

On 2023/2/24 02:29, Eric Biggers wrote:
> Hi,
> 
> On Wed, Feb 08, 2023 at 05:33:22PM +0800, Gao Xiang wrote:
>> From: Sandeep Dhavale <dhavale@google.com>
>>
>> Using per-cpu thread pool we can reduce the scheduling latency compared
>> to workqueue implementation. With this patch scheduling latency and
>> variation is reduced as per-cpu threads are high priority kthread_workers.
>>
>> The results were evaluated on arm64 Android devices running 5.10 kernel.
> 
> I see that this patch was upstreamed.  Meanwhile, commit c25da5b7baf1d
> ("dm verity: stop using WQ_UNBOUND for verify_wq") was also upstreamed.
> 
> Why is this more complex solution better than simply removing WQ_UNBOUND?

I do think it's a specific issue on specific arm64 hardwares (assuming
qualcomm, I don't know) since WQ_UNBOUND decompression once worked well
on the hardwares I once used (I meant Hisilicon, and most x86_64 CPUs,
I tested at that time) compared with per-cpu workqueue.

Also RT threads are also matchable with softirq approach.  In addition,
many configurations work without dm-verity.

I don't have more time to dig into it for now but it's important to
resolve this problem on some arm64 hardwares first.  Also it's an
optional stuff, if the root cause of workqueue issue can be resolved,
we could consider drop it then.

Thsnka,
Gao Xiang

> 
> - Eric

  reply	other threads:[~2023-02-23 18:53 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-08  9:33 Gao Xiang
2023-02-23 18:29 ` Eric Biggers
2023-02-23 18:52   ` Gao Xiang [this message]
2023-02-23 19:08     ` Gao Xiang
2023-02-24  0:13       ` Sandeep Dhavale
2023-02-28  4:47         ` Sandeep Dhavale
2023-02-28  5:01           ` Gao Xiang
2023-02-28  5:51             ` Sandeep Dhavale
2023-02-28  5:58               ` Gao Xiang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ca1e604a-92ba-023b-8896-dcad9413081d@linux.alibaba.com \
    --to=hsiangkao@linux.alibaba.com \
    --cc=chao@kernel.org \
    --cc=dhavale@google.com \
    --cc=ebiggers@kernel.org \
    --cc=huyue2@coolpad.com \
    --cc=jefflexu@linux.alibaba.com \
    --cc=kernel-team@android.com \
    --cc=linux-erofs@lists.ozlabs.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nhuck@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®