Hi, On Fri, Jul 08, 2022 at 12:49:07PM +0800, guowei du wrote: > hi, > I am sorry，there is only one patch. > > If two or more tasks are doing a shrinking job, there are different results > for each task. > That is to say, the status of each task is not persistent each time, > although they have > the same purpose to release memory. > > And, If two tasks are shrinking, the erofs_sb_list will become no order, > because each task will > move one sbi to tail, but sbi is random, so results are more complex.
Thanks for the explanation. So it doesn't sound like a real issue but seems like an improvement? If it's more like this, you could patch this to the products first and beta for more time and see if it works well.. I'm more careful about such change to shrinker since it could impact downstream users... Yes, I know this behavior, but I'm not sure if it's needed to be treated as this way, because in principle shrinker can be processed by multiple tasks since otherwise it could be stuck by some low priority task (I remember it sometimes happens in Android.) > > Because of the use of the local variable 'run_no', it took me a long time > to understand the > procedure of each task when they are concurrent. > > There is the same issue for other fs, such as > fs/ubifs/shrink.c、fs/f2fs/shrink.c. > > If scan_objects cost a long time ,it will trigger a watchdog, shrinking > should > not make work time-consuming. It should be done ASAP. > So, I add a new spin lock to let tasks shrink fs sequentially, it will just > make all tasks shrink > one by one. Actually such shrinker is used for managed slots (sorry I needs more work to rename workgroup to such name). But currently one of my ongoing improvements is to remove pclusters immediately from managed slots if no compressed buffer is cached, so it's used for inflight I/Os (to merge decompression requests, including ongoing deduplication requests) and cached I/O only. So in that way objects will be more fewer than now. > > > Thanks very much. Thank you. Thanks, Gao Xiang
