Messages in this thread | | | Subject | Re: [f2fs-dev] [PATCH v3] f2fs: change virtual mapping way for compression pages | From | Chao Yu <> | Date | Fri, 4 Sep 2020 15:11:26 +0800 |
| |
Hi Daeho,
Could you please clean up a bit on this patch, we can wrap vm_map_ram loop logic into f2fs_vmap() as below:
f2fs_vmap() { for (i = 0; i < MAX_VMAP_RETRIES; i++) { cc->cbuf = vm_map_ram(cc->cpages, cc->nr_cpages, -1); if (cc->cbuf) break; vm_unmap_aliases(); } }
How do you think of this?
Thanks,
On 2020/8/13 17:09, Chao Yu wrote: > On 2020/8/12 13:17, Daeho Jeong wrote: >> From: Daeho Jeong <daehojeong@google.com> >> >> By profiling f2fs compression works, I've found vmap() callings have >> unexpected hikes in the execution time in our test environment and >> those are bottlenecks of f2fs decompression path. Changing these with >> vm_map_ram(), we can enhance f2fs decompression speed pretty much. >> >> [Verification] >> Android Pixel 3(ARM64, 6GB RAM, 128GB UFS) >> Turned on only 0-3 little cores(at 1.785GHz) >> >> dd if=/dev/zero of=dummy bs=1m count=1000 >> echo 3 > /proc/sys/vm/drop_caches >> dd if=dummy of=/dev/zero bs=512k >> >> - w/o compression - >> 1048576000 bytes (0.9 G) copied, 2.082554 s, 480 M/s >> 1048576000 bytes (0.9 G) copied, 2.081634 s, 480 M/s >> 1048576000 bytes (0.9 G) copied, 2.090861 s, 478 M/s >> >> - before patch - >> 1048576000 bytes (0.9 G) copied, 7.407527 s, 135 M/s >> 1048576000 bytes (0.9 G) copied, 7.283734 s, 137 M/s >> 1048576000 bytes (0.9 G) copied, 7.291508 s, 137 M/s >> >> - after patch - >> 1048576000 bytes (0.9 G) copied, 1.998959 s, 500 M/s >> 1048576000 bytes (0.9 G) copied, 1.987554 s, 503 M/s >> 1048576000 bytes (0.9 G) copied, 1.986380 s, 503 M/s >> >> Signed-off-by: Daeho Jeong <daehojeong@google.com> > > Reviewed-by: Chao Yu <yuchao0@huawei.com> > > Thanks, > > > _______________________________________________ > Linux-f2fs-devel mailing list > Linux-f2fs-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel > . >
| |