Hello, Christoph. I'm semi-offline for a few weeks, so please pardon the tardiness and brevity. On Wed, Mar 29, 2023 at 01:34:48AM +0200, Christoph Hellwig wrote: > On Tue, Mar 28, 2023 at 05:18:43PM -0400, Chris Mason wrote: > btrfs is the only place offloading writes from the per-cgroup writeback > to it's own not cgroup aware workqueues. > > Offloading from one writeback thread to another threadpool to just > offload back to another thread to not deadlock is obviously not > an actual smart thing to do, and fortunately no one else is doing > this. We didn't really look deep into adding the support but Chris mentioned that raid5/6 are likely to need something similar. Maybe this is because my grasp of filesytsems is pretty weak but the pattern doesn't seem unreasonable to me. There's some work to be done by a shread kthread and that sometimes can fork out IOs which belong to specific cgroups. > For btrfs it is on it's way out by not doing the offload just for > checksumming in a little bit, and even for compression the right fix > is just to allow more than one thread per device and cgroup. I plan > to look into that, but there's plenty higher priority work right now. At least in the IO control and direct issue path, punting to just one thread hasn't been a practical problem given that when the issuing thread needs to be blocked, either the whole device or the cgroup needs to be throttled anyway. Are you thinking about scenarios where substantial CPU cycles are consumed for IOs (e.g. dm-crypt)? Thanks. -- tejun
