Messages in this thread |  | | From | Linus Torvalds <> | Date | Tue, 23 May 2023 10:59:33 -0700 | Subject | Re: [PATCHSET v1 wq/for-6.5] workqueue: Improve unbound workqueue execution locality |
| |
On Mon, May 22, 2023 at 6:51 PM Linus Torvalds <torvalds@linux-foundation.org> wrote: > > Ok, looks good, consider me convinced.
Ugh, and I just got the erofs pull, which made me aware of how there's *another* hack for "worker threads don't work well on Android", which now doubled down on setting special scheduler flags for them too.
See commit cf7f2732b4b8 ("erofs: use HIPRI by default if per-cpu kthreads are enabled"), but the whole deeper problem goes back much further (commit 3fffb589b9a6: "erofs: add per-cpu threads for decompression as an option").
See also
https://lore.kernel.org/lkml/CAB=BE-SBtO6vcoyLNA9F-9VaN5R0t3o_Zn+FW8GbO6wyUqFneQ@mail.gmail.com/
I really hate how we have random drivers and filesystems doing random workarounds for "kthread workers don't work well enough, so add random tweaks".
> I still would like to hear from the actual arm crowd that caused this > all and have those odd BIG.little cases.
Sandeep, any chance that you could try out Tejun's series with plain workers, and compare it to the percpu threads?
See
https://lore.kernel.org/lkml/20230519001709.2563-1-tj@kernel.org/
for the beginning of this thread. The aim really is to try to figure out - and hopefully fix - the fact that Android loads seem to trigger all these random hacks that don't make any sense on a high level, and seem to be workarounds rather than real fixes. Scheduling percpu workers is a horrible horrible fix and not at all good in general, and it would be much better if we could just improve workqueue behavior in the odd Android situation.
Linus
|  |