On Apr 23, 2024 / 17:35, Tejun Heo wrote: > Hello, > > On Wed, Apr 24, 2024 at 12:36:45AM +0000, Shinichiro Kawasaki wrote: > > Hello Tejun, thanks for the fix. I confirmed that the number of in-flight works > > become larger than 8 during the unmount operation. > > > > total infl CPUtime CPUitsv CMW/RPR mayday rescued > > dmz_cwq_dmz_dml_072 613 33 4.6 - 0 0 0 > > > > total infl CPUtime CPUitsv CMW/RPR mayday rescued > > dmz_cwq_dmz_dml_072 617 33 4.7 - 0 0 0 > > > > total infl CPUtime CPUitsv CMW/RPR mayday rescued > > dmz_cwq_dmz_dml_072 619 33 4.8 - 0 0 0 > > > > > > Also I measured xfs unmount time of 10 times. Its avarage is as follows. > > > > Kernel | Unmount time > > ----------------------+-------------- > > v6.8 | 29m 3s > > v6.9-rc2 | 34m 17s > > v6.9-rc2 + Tejun fix | 30m 55s > > > > We can see that the fix reduced the unmount time, which is great! Still there is > > a gap from v6.8 kernel. I think this gap can be a left work, and hope the fix > > patch to be upstreamed. > > So, v6.8 was buggy in that it allowed a lot higher concurrency than > requested. If higher concurrency is desirable, you can just set @max_active > to a higher number. Currently, the absolute maximum is 512 (WQ_MAX_ACTIVE) > but that number was picked arbitrarily probably more than a decade ago, so > if you find higher concurrency useful, we can definitely push up that > number. Thanks for the explanation. Now I see why the gap exists between v6.8 kernel and v6.9-rc2 kernel + fix. To confirm it, I tried @max_active = WQ_MAX_ACTIVE on top of the fix, and got the xfs unmount time (10 times average). Kernel | Unmount time -------------------------------------------------+-------------- v6.9-rc2 + Tejun fix + @max_active WQ_MAX_ACTIVE | 29m 27s It looks comparable with v6.8 kernel :) At this point, I think the default @max_active is enough. If anyone requests better dm-zoned performance, I will revisit the improvement opportunity by the larger @max_active.
