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