On Mon, Jul 24, 2023 at 11:42 AM Guoqing Jiang <guoqing.jiang@xxxxxxxxx> wrote:
>
> Hi,
>
> On 7/19/23 17:36, Fengnan Chang wrote:
> > In commit a015434480dc("ext4: send parallel discards on commit
> > completions"), issue all discard commands in parallel make all
> > bios could merged into one request, so lowlevel drive can issue
> > multi segments in one time which is more efficiency, but commit
> > 55cdd0af2bc5 ("ext4: get discard out of jbd2 commit kthread contex")
> > seems broke this way, let's fix it.
> > In my test, the time of fstrim fs with multi big sparse file
> > reduce from 6.7s to 1.3s.
>
> I tried with a 20T sparse file with latest kernel (6.5-rc2+ commit
> f7e3a1baf).
>
> truncate -s 20T sparse1.img
> mkfs.ext4 sparse1.img
> mount -o discard sparse1.img /mnt/
> time fstrim /mnt
>
> 1. without the patch
>
> [root@localhost ~]# time fstrim /mnt
>
> real 0m13.496s
> user 0m0.002s
> sys 0m5.202s
>
> 2. with the patch
>
> [root@localhost ~]# time fstrim /mnt
>
> real 0m15.956s
> user 0m0.000s
> sys 0m7.251s
>
> The result is different from your side, could you share your test?
Here are my test steps:
1. create 10 normal files, each file size is 10G.
2. deallocate file：punch holes every 16k. The attached file includes step 1&2.
3. trim all fs.
So why does trim a new fs become slow? because with my patch, in
ext4_try_to_trim_range
we need do alloc and free memory, this might cause 9us cost in
addition. So in current
version, benefits can only be gained if there are multiple
discontinuous segments that
need to be trimmed in ext4_try_to_trim_range.
This problem needs to be fixed, so I'll send another version.
Thanks.
Fengnan
>
> Thanks,
> Guoqing
Attachment:
makefrag.c
Description: Binary data
