* [f2fs-dev] f2fs compress performance problem @ 2021-06-04 7:31 changfengnan 2021-07-01 17:06 ` Jaegeuk Kim 0 siblings, 1 reply; 5+ messages in thread From: changfengnan @ 2021-06-04 7:31 UTC (permalink / raw) To: jaegeuk, 'Chao Yu', linux-f2fs-devel Hi: I've been working on f2fs compression for a while, I'm confused on f2fs compression performance, after a while reserch, I found some problem, maybe need some discuss. I use AndroBench test performance on mobile, after enable compression, the benchmark scores have dropped a lot. Specifically: 1. 32M sequential read has dropped to 50% of original. Test case open file with O_RDONLY|O_DIRECT, and set POSIX_FADV_RANDOM, the major resaon is disable readahed. For now,I didn't found any patch can improve this. 2. 4K random read has dropped to 40% of original, after merge `f2fs: compress: add compress_inode to cache compressed blocks`, significant improvement in random read performance, up to 90% of original, maybe more. 3. 32M sequential overwrite has dropped to 10% of original, after merge `f2fs: compress: remove unneeded read when rewrite whole cluster` up to 30% of original. 4. 4K random read has dropped to 1% of original, yes only 1% of original, I found open file with O_WRONLY|O_DSYNC|O_DIRECT is an important reason, every time sync a compress inode need do checkpoint, after I remove checkpoint on compress inode, up to 10% of original. And I think major reason of this is we need read whole cluster and rewrite it ,but I did't think of any method to improve this. I want to know is there any idea can help to improve this. And I want to know do we have goal for the performance of compression, is it possible to achieve the original performance? Thanks. _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [f2fs-dev] f2fs compress performance problem 2021-06-04 7:31 [f2fs-dev] f2fs compress performance problem changfengnan @ 2021-07-01 17:06 ` Jaegeuk Kim 2021-07-02 2:40 ` Fengnan Chang 0 siblings, 1 reply; 5+ messages in thread From: Jaegeuk Kim @ 2021-07-01 17:06 UTC (permalink / raw) To: changfengnan; +Cc: linux-f2fs-devel On 06/04, changfengnan@vivo.com wrote: > Hi: > > I've been working on f2fs compression for a while, I'm confused on f2fs > compression performance, after a while reserch, > I found some problem, maybe need some discuss. > I use AndroBench test performance on mobile, after enable compression, the > benchmark scores have dropped a lot. > Specifically: > 1. 32M sequential read has dropped to 50% of original. Test case open file > with O_RDONLY|O_DIRECT, and set POSIX_FADV_RANDOM, the major resaon > is disable readahed. For now,I didn't found any patch can improve this. > 2. 4K random read has dropped to 40% of original, after merge `f2fs: > compress: add compress_inode to cache compressed blocks`, > significant improvement in random read performance, up to 90% of original, > maybe more. > 3. 32M sequential overwrite has dropped to 10% of original, after merge > `f2fs: compress: remove unneeded read when rewrite whole cluster` > up to 30% of original. > 4. 4K random read has dropped to 1% of original, yes only 1% of original, I > found open file with O_WRONLY|O_DSYNC|O_DIRECT is an important reason, > every time sync a compress inode need do checkpoint, after I remove > checkpoint on compress inode, up to 10% of original. And I think major > reason of this > is we need read whole cluster and rewrite it ,but I did't think of any > method to improve this. > > I want to know is there any idea can help to improve this. > And I want to know do we have goal for the performance of compression, is it > possible to achieve the original performance? Could you please check compress_cache and extent_cache that can improve read performance? Both were done quite recently. > > Thanks. _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [f2fs-dev] f2fs compress performance problem 2021-07-01 17:06 ` Jaegeuk Kim @ 2021-07-02 2:40 ` Fengnan Chang 2021-07-02 6:24 ` Jaegeuk Kim 0 siblings, 1 reply; 5+ messages in thread From: Fengnan Chang @ 2021-07-02 2:40 UTC (permalink / raw) To: Jaegeuk Kim; +Cc: linux-f2fs-devel Yes, I had enable compress_cache and extent_cache, compress_cache indeed can improve random read performance, but couldn't improve other test case.And extent_cache was default enabled in my test. Fix the description of the previous email: 4. 4K random overwrite has dropped to 1% of original, yes only 1% of original, I found open file with O_WRONLY|O_DSYNC|O_DIRECT is an important reason, every time sync a compress inode need do checkpoint, after I remove checkpoint on compress inode, up to 10% of original. If I set write size equal to cluster size, it can up to 35% of original. And I think major reason of this is we need read whole cluster and rewrite it , I've been trying to get around this restriction recently, but haven't made any progress yet. Thanks. On 2021/7/2 1:06, Jaegeuk Kim wrote: > On 06/04, changfengnan@vivo.com wrote: >> Hi: >> >> I've been working on f2fs compression for a while, I'm confused on f2fs >> compression performance, after a while reserch, >> I found some problem, maybe need some discuss. >> I use AndroBench test performance on mobile, after enable compression, the >> benchmark scores have dropped a lot. >> Specifically: >> 1. 32M sequential read has dropped to 50% of original. Test case open file >> with O_RDONLY|O_DIRECT, and set POSIX_FADV_RANDOM, the major resaon >> is disable readahed. For now,I didn't found any patch can improve this. >> 2. 4K random read has dropped to 40% of original, after merge `f2fs: >> compress: add compress_inode to cache compressed blocks`, >> significant improvement in random read performance, up to 90% of original, >> maybe more. >> 3. 32M sequential overwrite has dropped to 10% of original, after merge >> `f2fs: compress: remove unneeded read when rewrite whole cluster` >> up to 30% of original. >> 4. 4K random read has dropped to 1% of original, yes only 1% of original, I >> found open file with O_WRONLY|O_DSYNC|O_DIRECT is an important reason, >> every time sync a compress inode need do checkpoint, after I remove >> checkpoint on compress inode, up to 10% of original. And I think major >> reason of this >> is we need read whole cluster and rewrite it ,but I did't think of any >> method to improve this. >> >> I want to know is there any idea can help to improve this. >> And I want to know do we have goal for the performance of compression, is it >> possible to achieve the original performance? > > Could you please check compress_cache and extent_cache that can improve read > performance? Both were done quite recently. > >> >> Thanks. > _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [f2fs-dev] f2fs compress performance problem 2021-07-02 2:40 ` Fengnan Chang @ 2021-07-02 6:24 ` Jaegeuk Kim 2021-07-06 13:12 ` Fengnan Chang 0 siblings, 1 reply; 5+ messages in thread From: Jaegeuk Kim @ 2021-07-02 6:24 UTC (permalink / raw) To: Fengnan Chang; +Cc: linux-f2fs-devel On 07/02, Fengnan Chang wrote: > Yes, I had enable compress_cache and extent_cache, compress_cache indeed can > improve random read performance, but couldn't improve other test case.And > extent_cache was default enabled in my test. Sorry, we enabled extent_cache for RO partition only. static inline bool f2fs_may_extent_tree(struct inode *inode) { struct f2fs_sb_info *sbi = F2FS_I_SB(inode); if (!test_opt(sbi, EXTENT_CACHE) || is_inode_flag_set(inode, FI_NO_EXTENT) || (is_inode_flag_set(inode, FI_COMPRESSED_FILE) && !f2fs_sb_has_readonly(sbi))) return false; ... > > > Fix the description of the previous email: > 4. 4K random overwrite has dropped to 1% of original, yes only 1% of > original, I found open file with O_WRONLY|O_DSYNC|O_DIRECT is an important > reason, every time sync a compress inode need do checkpoint, after I remove > checkpoint on compress inode, up to 10% of original. If I set write size > equal to cluster size, it can up to 35% of original. And I think major > reason of this is we need read whole cluster and rewrite it , I've been > trying to get around this restriction recently, but haven't made any > progress yet. > > Thanks. > > On 2021/7/2 1:06, Jaegeuk Kim wrote: > > On 06/04, changfengnan@vivo.com wrote: > > > Hi: > > > > > > I've been working on f2fs compression for a while, I'm confused on f2fs > > > compression performance, after a while reserch, > > > I found some problem, maybe need some discuss. > > > I use AndroBench test performance on mobile, after enable compression, the > > > benchmark scores have dropped a lot. > > > Specifically: > > > 1. 32M sequential read has dropped to 50% of original. Test case open file > > > with O_RDONLY|O_DIRECT, and set POSIX_FADV_RANDOM, the major resaon > > > is disable readahed. For now,I didn't found any patch can improve this. > > > 2. 4K random read has dropped to 40% of original, after merge `f2fs: > > > compress: add compress_inode to cache compressed blocks`, > > > significant improvement in random read performance, up to 90% of original, > > > maybe more. > > > 3. 32M sequential overwrite has dropped to 10% of original, after merge > > > `f2fs: compress: remove unneeded read when rewrite whole cluster` > > > up to 30% of original. > > > 4. 4K random read has dropped to 1% of original, yes only 1% of original, I > > > found open file with O_WRONLY|O_DSYNC|O_DIRECT is an important reason, > > > every time sync a compress inode need do checkpoint, after I remove > > > checkpoint on compress inode, up to 10% of original. And I think major > > > reason of this > > > is we need read whole cluster and rewrite it ,but I did't think of any > > > method to improve this. > > > > > > I want to know is there any idea can help to improve this. > > > And I want to know do we have goal for the performance of compression, is it > > > possible to achieve the original performance? > > > > Could you please check compress_cache and extent_cache that can improve read > > performance? Both were done quite recently. > > > > > > > > Thanks. > > _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [f2fs-dev] f2fs compress performance problem 2021-07-02 6:24 ` Jaegeuk Kim @ 2021-07-06 13:12 ` Fengnan Chang 0 siblings, 0 replies; 5+ messages in thread From: Fengnan Chang @ 2021-07-06 13:12 UTC (permalink / raw) To: Jaegeuk Kim; +Cc: linux-f2fs-devel I did more test on random overwrite, I set write size equal to cluster size, make sure always write one cluster, no cross cluster write and merge this patch https://lore.kernel.org/linux-f2fs-devel/6bd41278-0de8-5119-6857-0478c641cf71@vivo.com/T/#t , it can up to 45% of original. This would seem to indicate that there are reasons other than the need for read whole cluster and rewrite it. On 2021/7/2 14:24, Jaegeuk Kim wrote: > On 07/02, Fengnan Chang wrote: >> Yes, I had enable compress_cache and extent_cache, compress_cache indeed can >> improve random read performance, but couldn't improve other test case.And >> extent_cache was default enabled in my test. > > Sorry, we enabled extent_cache for RO partition only. > > static inline bool f2fs_may_extent_tree(struct inode *inode) > { > struct f2fs_sb_info *sbi = F2FS_I_SB(inode); > > if (!test_opt(sbi, EXTENT_CACHE) || > is_inode_flag_set(inode, FI_NO_EXTENT) || > (is_inode_flag_set(inode, FI_COMPRESSED_FILE) && > !f2fs_sb_has_readonly(sbi))) > return false; > ... > > >> >> >> Fix the description of the previous email: >> 4. 4K random overwrite has dropped to 1% of original, yes only 1% of >> original, I found open file with O_WRONLY|O_DSYNC|O_DIRECT is an important >> reason, every time sync a compress inode need do checkpoint, after I remove >> checkpoint on compress inode, up to 10% of original. If I set write size >> equal to cluster size, it can up to 35% of original. And I think major >> reason of this is we need read whole cluster and rewrite it , I've been >> trying to get around this restriction recently, but haven't made any >> progress yet. >> >> Thanks. >> >> On 2021/7/2 1:06, Jaegeuk Kim wrote: >>> On 06/04, changfengnan@vivo.com wrote: >>>> Hi: >>>> >>>> I've been working on f2fs compression for a while, I'm confused on f2fs >>>> compression performance, after a while reserch, >>>> I found some problem, maybe need some discuss. >>>> I use AndroBench test performance on mobile, after enable compression, the >>>> benchmark scores have dropped a lot. >>>> Specifically: >>>> 1. 32M sequential read has dropped to 50% of original. Test case open file >>>> with O_RDONLY|O_DIRECT, and set POSIX_FADV_RANDOM, the major resaon >>>> is disable readahed. For now,I didn't found any patch can improve this. >>>> 2. 4K random read has dropped to 40% of original, after merge `f2fs: >>>> compress: add compress_inode to cache compressed blocks`, >>>> significant improvement in random read performance, up to 90% of original, >>>> maybe more. >>>> 3. 32M sequential overwrite has dropped to 10% of original, after merge >>>> `f2fs: compress: remove unneeded read when rewrite whole cluster` >>>> up to 30% of original. >>>> 4. 4K random read has dropped to 1% of original, yes only 1% of original, I >>>> found open file with O_WRONLY|O_DSYNC|O_DIRECT is an important reason, >>>> every time sync a compress inode need do checkpoint, after I remove >>>> checkpoint on compress inode, up to 10% of original. And I think major >>>> reason of this >>>> is we need read whole cluster and rewrite it ,but I did't think of any >>>> method to improve this. >>>> >>>> I want to know is there any idea can help to improve this. >>>> And I want to know do we have goal for the performance of compression, is it >>>> possible to achieve the original performance? >>> >>> Could you please check compress_cache and extent_cache that can improve read >>> performance? Both were done quite recently. >>> >>>> >>>> Thanks. >>> > _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2021-07-06 13:12 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2021-06-04 7:31 [f2fs-dev] f2fs compress performance problem changfengnan 2021-07-01 17:06 ` Jaegeuk Kim 2021-07-02 2:40 ` Fengnan Chang 2021-07-02 6:24 ` Jaegeuk Kim 2021-07-06 13:12 ` Fengnan Chang
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.