On Thu 11-09-25 14:01:36, Jan Kara wrote: > On Thu 11-09-25 13:30:13, Jan Kara wrote: > > On Wed 10-09-25 07:10:12, Tejun Heo wrote: > > > Hello, Jan. > > > > > > On Wed, Sep 10, 2025 at 10:19:36AM +0200, Jan Kara wrote: > > > > Well, reducing @max_active to 1 will certainly deal with the list_lock > > > > contention as well. But I didn't want to do that as on a busy container > > > > system I assume there can be switching happening between different pairs of > > > > cgroups. With the approach in this patch switches with different target > > > > cgroups can still run in parallel. I don't have any real world data to back > > > > that assumption so if you think this parallelism isn't really needed and we > > > > are fine with at most one switch happening in the system, switching > > > > max_active to 1 is certainly simple enough. > > > > > > What bothers me is that the concurrency doesn't match between the work items > > > being scheduled and the actual execution and we're resolving that by early > > > exiting from some work items. It just feels like an roundabout way to do it > > > with extra code. I think there are better ways to achieve per-bdi_writeback > > > concurrency: > > > > > > - Move work_struct from isw to bdi_writeback and schedule the work item on > > > the target wb which processes isw's queued on the bdi_writeback. > > > > > > - Or have a per-wb workqueue with max_active limit so that concurrency is > > > regulated per-wb. > > > > > > The latter is a bit simpler but does cost more memory as workqueue_struct > > > isn't tiny. The former is a bit more complicated but most likely less so > > > than the current code. What do you think? > > > > That's a fair objection and good idea. I'll rework the patch to go with > > the first variant. > > I've realized why I didn't do something like this from the beginning. The > slight snag is that you can start switching inode's wb only once rcu period > expires (so that I_WB_SWITCH setting is guaranteed to be visible). This > makes moving the work struct to bdi_writeback sligthly tricky. It shouldn't > be too bad so I think I'll try it and see how it looks like. It actually worked out pretty nicely I think. Posting v2 with the changes... Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR
