Got it.

Thanks very much.

On Fri, Jul 8, 2022 at 1:41 PM Gao Xiang <hsiangkao@linux.alibaba.com>
wrote:

> 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
>
>