Sounds good :-)  Perhaps it's simply that zstd needs a lot of memory to 
operate, however it's unfortunate that it doesn't work on smaller platforms 
"out of the box" like lz4 does.  Should there a be note or guidance of some 
sort regarding this for smaller embedded platforms?

On Mon, Aug 31, 2020, at 11:04 AM, Jaegeuk Kim wrote:
> Let me add more f2fs folks. :)
> 
> On 08/27, 5kft wrote:
> > (Note that for testing this I backported f2fs from 5.9-rc2 into 5.8.5, as I 
> > don't have 5.9 working on these boards yet.)
> > 
> > On Thu, Aug 27, 2020, at 7:39 AM, 5kft wrote:
> > > Quick update - I encounter the problem with f2fs zstd compression in the 
> > > mainline 5.9-rc2 kernel as well - e.g.,
> > > 
> > > [   67.668529] F2FS-fs (mmcblk0p1): Found nat_bits in checkpoint 
> > > [   68.339021] F2FS-fs (mmcblk0p1): Mounted with checkpoint version = 
> > > 76732978
> > > [   93.862327] kworker/u8:2: page allocation failure: order:6, 
> > > mode:0x40c40(GFP_NOFS|__GFP_COMP), nodemask=(null),cpuset=/,mems_allowed=0
> > > [   93.862360] CPU: 0 PID: 187 Comm: kworker/u8:2 Tainted: G         C    
> > >     5.8.5-sunxi #trunk
> > > [   93.862364] Hardware name: Allwinner sun8i Family
> > > [   93.862388] Workqueue: writeback wb_workfn (flush-179:0)
> > > [   93.862424] [<c010d6d5>] (unwind_backtrace) from [<c0109a55>] 
> > > (show_stack+0x11/0x14)
> > > [   93.862439] [<c0109a55>] (show_stack) from [<c056eae9>] 
> > > (dump_stack+0x75/0x84)
> > > [   93.862456] [<c056eae9>] (dump_stack) from [<c0243b8f>] 
> > > (warn_alloc+0xa3/0x104)
> > > [   93.862469] [<c0243b8f>] (warn_alloc) from [<c0244777>] 
> > > (__alloc_pages_nodemask+0xb87/0xc40)
> > > [   93.862483] [<c0244777>] (__alloc_pages_nodemask) from [<c02267fd>] 
> > > (kmalloc_order+0x19/0x38)
> > > [   93.862492] [<c02267fd>] (kmalloc_order) from [<c0226835>] 
> > > (kmalloc_order_trace+0x19/0x90)
> > > [   93.862506] [<c0226835>] (kmalloc_order_trace) from [<c047ddf5>] 
> > > (zstd_init_compress_ctx+0x51/0xfc)
> > > [   93.862518] [<c047ddf5>] (zstd_init_compress_ctx) from [<c047f90b>] 
> > > (f2fs_write_multi_pages+0x27b/0x6a0)
> > > [   93.862532] [<c047f90b>] (f2fs_write_multi_pages) from [<c046630d>] 
> > > (f2fs_write_cache_pages+0x415/0x538)
> > > [   93.862542] [<c046630d>] (f2fs_write_cache_pages) from [<c0466663>] 
> > > (f2fs_write_data_pages+0x233/0x264)
> > > [   93.862555] [<c0466663>] (f2fs_write_data_pages) from [<c0210ded>] 
> > > (do_writepages+0x35/0x98)
> > > [   93.862571] [<c0210ded>] (do_writepages) from [<c0290c4f>] 
> > > (__writeback_single_inode+0x2f/0x358)
> > > [   93.862584] [<c0290c4f>] (__writeback_single_inode) from [<c02910fd>] 
> > > (writeback_sb_inodes+0x185/0x378)
> > > [   93.862594] [<c02910fd>] (writeback_sb_inodes) from [<c0291321>] 
> > > (__writeback_inodes_wb+0x31/0x88)
> > > [   93.862603] [<c0291321>] (__writeback_inodes_wb) from [<c029156b>] 
> > > (wb_writeback+0x1f3/0x264)
> > > [   93.862612] [<c029156b>] (wb_writeback) from [<c0292461>] 
> > > (wb_workfn+0x24d/0x3a4)
> > > [   93.862624] [<c0292461>] (wb_workfn) from [<c0130b2f>] 
> > > (process_one_work+0x15f/0x3b0)
> > > [   93.862634] [<c0130b2f>] (process_one_work) from [<c0130e7b>] 
> > > (worker_thread+0xfb/0x3e0)
> > > [   93.862646] [<c0130e7b>] (worker_thread) from [<c0135c3b>] 
> > > (kthread+0xeb/0x10c)
> > > [   93.862656] [<c0135c3b>] (kthread) from [<c0100159>] 
> > > (ret_from_fork+0x11/0x38)
> > > [   93.862661] Exception stack(0xd4167fb0 to 0xd4167ff8)
> > > [   93.862667] 7fa0:                                     00000000 
> > > 00000000 00000000 00000000
> > > [   93.862674] 7fc0: 00000000 00000000 00000000 00000000 00000000 
> > > 00000000 00000000 00000000
> > > [   93.862680] 7fe0: 00000000 00000000 00000000 00000000 00000013 00000000
> > > [   93.862686] Mem-Info:
> > > [   93.862699] active_anon:3457 inactive_anon:6470 isolated_anon:32
> > >                 active_file:14148 inactive_file:75224 isolated_file:0
> > >                 unevictable:4 dirty:10374 writeback:151
> > >                 slab_reclaimable:4946 slab_unreclaimable:8951
> > >                 mapped:5557 shmem:414 pagetables:332 bounce:0
> > >                 free:5946 free_pcp:118 free_cma:4292
> > > [   93.862709] Node 0 active_anon:13828kB inactive_anon:26032kB 
> > > active_file:56592kB inactive_file:300896kB unevictable:16kB 
> > > isolated(anon):0kB isolated(file):0kB mapped:22228kB dirty:41496kB 
> > > writeback:604kB shmem:1656kB writeback_tmp:0kB all_unreclaimable? no
> > > [   93.862725] Normal free:23784kB min:6904kB low:7604kB high:8304kB 
> > > reserved_highatomic:0KB active_anon:13956kB inactive_anon:25800kB 
> > > active_file:56592kB inactive_file:301212kB unevictable:16kB 
> > > writepending:42024kB present:524288kB managed:503888kB mlocked:16kB 
> > > kernel_stack:1200kB pagetables:1328kB bounce:0kB free_pcp:472kB 
> > > local_pcp:196kB free_cma:17168kB
> > > [   93.862727] lowmem_reserve[]: 0 0 0
> > > [   93.862734] Normal: 95*4kB (UMEC) 122*8kB (UMEC) 45*16kB (UMEC) 
> > > 32*32kB (UMEC) 17*64kB (UMEC) 7*128kB (UMEC) 4*256kB (U) 3*512kB (UC) 
> > > 0*1024kB 0*2048kB 4*4096kB (C) = 24028kB
> > > [   93.862762] 89790 total pagecache pages
> > > [   93.862768] 0 pages in swap cache
> > > [   93.862771] Swap cache stats: add 0, delete 0, find 0/0
> > > [   93.862773] Free swap  = 251940kB
> > > [   93.862775] Total swap = 251940kB
> > > [   93.862777] 131072 pages RAM
> > > [   93.862780] 0 pages HighMem/MovableOnly
> > > [   93.862782] 5100 pages reserved
> > > [   93.862784] 32768 pages cma reserved
> > > 
> > > I haven't tried lowering MAX_COMPRESS_LOG_SIZE in this kernel yet but 
> > > will test this when I can.
> > > 
> > > On Tue, Aug 25, 2020, at 1:31 PM, 5kft wrote:
> > >> Note that I don't think that this particular problem is a memleak as it 
> > >> happens very quickly when simply copying files to the zstd-mounted 
> > >> filesystem - but I haven't been able to compare the 5.8.3 changes to 
> > >> 5.9-rc1 yet.  This particular board boots up with vm.min_free_kbytes = 
> > >> 2406, which seems pretty low, but the board only has 512MB RAM on it 
> > >> total.  Kind of crazy I know, but it's a good test case for this problem 
> > >> :-)  Also, again lz4 compression works fine at this low value.
> > >> 
> > >> I'm not sure that this particular change (lowering 
> > >> MAX_COMPRESS_LOG_SIZE) helps significantly.  I'm still seeing the 
> > >> failures even with vm.mem_free_kbytes = 32768 (and this seems like a 
> > >> rather high value compared to the default).
> > >> 
> > >> On Tue, Aug 25, 2020, at 12:43 PM, Jaegeuk Kim wrote:
> > >>> So, if there's no memleak in f2fs but we need to do something like 
> > >>> that, I feel that something is misconfigured in f2fs wrt zstd.
> > >>> I took a look at zstd initialization flow, it seems f2fs is asking too 
> > >>> much memory space for the workspace when comparing it with btrfs.
> > >>> Could you please check whether replacing the below "8" with "5" 
> > >>> mitigates the problem? ("5" is used in btrfs.)
> > >>> 
> > >>> In fs/f2fs/f2fs.h,
> > >>> #define MAX_COMPRESS_LOG_SIZE           8
> > >>> 
> > >>> 
> > >>> 
> > >>> 2020년 8월 25일 (화) 오후 12:30, 5kft <[email protected]>님이 작성:
> > >>>> __
> > >>>> Will do!  Quick question - should these changes handle a low 
> > >>>> "vm.min_free_kbytes" situation with f2fs?  I can workaround for now by 
> > >>>> increasing this value per-board, although I don't know how high to 
> > >>>> increase it to (and I'm not sure typical users of f2fs with 
> > >>>> compression would know how to determine the right value either).
> > >>>> 
> > >>>> On Tue, Aug 25, 2020, at 12:25 PM, Jaegeuk Kim wrote:
> > >>>>> Oh, can you try to get the diff from up-to-date f2fs?
> > >>>>> 
> > >>>>> # cd <5.8.3_branch>
> > >>>>> # git diff <5.9-rc1_branch> fs/f2fs
> > >>>>> 
> > >>>>> 2020년 8월 25일 (화) 오전 11:45, 5kft <[email protected]>님이 작성:
> > >>>>>> __
> > >>>>>> Indeed these changes are present in 5.8.3 (copy from the compress.c 
> > >>>>>> on my build):
> > >>>>>> 
> > >>>>>>                 err = f2fs_write_compressed_pages(cc, submitted, 
> > >>>>>>                                                         wbc, 
> > >>>>>> io_type);
> > >>>>>>                 cops->destroy_compress_ctx(cc);
> > >>>>>>                 kfree(cc->cpages);
> > >>>>>>                 cc->cpages = NULL;
> > >>>>>>                 if (!err)
> > >>>>>>                         return 0;
> > >>>>>> 
> > >>>>>> On Tue, Aug 25, 2020, at 11:37 AM, Jaegeuk Kim wrote:
> > >>>>>>> Hi,
> > >>>>>>> 
> > >>>>>>> Thank you for the test and report. :)
> > >>>>>>> 
> > >>>>>>> Just to make sure if there's any missing fixes, I guess the gap is 
> > >>>>>>> the recent 5.9-rc1 updates.
> > >>>>>>> Looking at a glance, potential memory leak was fixed by the below 
> > >>>>>>> commit among them. Could you give it a try?
> > >>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs-stable.git/commit/?h=linux-5.4.y&id=721ef9e46dec3091fa7cd955da99ce83a850ab32
> > >>>>>>> 
> > >>>>>>> Thanks,
> > >>>>>>> 
> > >>>>>>> 
> > >>>>>>> 2020년 8월 25일 (화) 오전 11:09, 5kft <[email protected]>님이 작성:
> > >>>>>>>> __
> > >>>>>>>> I did a little quick testing further on this problem, and I found 
> > >>>>>>>> that if I increase "vm.min_free_kbytes" then the allocations (not 
> > >>>>>>>> surprisingly) work and the failures go away.  E.g., this appears 
> > >>>>>>>> to make it work fine:
> > >>>>>>>> 
> > >>>>>>>>     sysctl -w vm.min_free_kbytes=65536
> > >>>>>>>> 
> > >>>>>>>> I didn't bisect this to find out what the lowest/safe minimum 
> > >>>>>>>> should be...
> > >>>>>>>> 
> > >>>>>>>> Is there a way that F2FS should indicate that a change like this 
> > >>>>>>>> may be necessary when using zstd compression on some platforms?  
> > >>>>>>>> Perhaps this is just a documentation addition?  I just want to 
> > >>>>>>>> save others from the pain of a potentially corrupted filesystem 
> > >>>>>>>> when using zstd compression because F2FS was internally running 
> > >>>>>>>> out of memory (which is what happened to me...)
> > >>>>>>>> 
> > >>>>>>>> Thanks!
> > >>>>>>>> 
> > >>>>>>>> On Tue, Aug 25, 2020, at 7:47 AM, 5kft wrote:
> > >>>>>>>>> Hi Jaegeuk,
> > >>>>>>>>> 
> > >>>>>>>>> First, I'd like to apologize in advance if a direct email isn't 
> > >>>>>>>>> appropriate for reporting bugs in f2fs; I'm not sure what the 
> > >>>>>>>>> accepted process is for reporting issues in F2FS.
> > >>>>>>>>> 
> > >>>>>>>>> I am a contributor to the Armbian project 
> > >>>>>>>>> (https://www.armbian.com/ and https://github.com/armbian), and 
> > >>>>>>>>> have been using compression in F2FS for some time now - very nice 
> > >>>>>>>>> work - LZ4 compression works great!  Unfortunately, however, when 
> > >>>>>>>>> I try using "zstd" compression, I consistently get numerous 
> > >>>>>>>>> kernel page allocation failures (and not surprisingly in some 
> > >>>>>>>>> cases corruption of data from the filesystem).  I've been seeing 
> > >>>>>>>>> this for some time but finally got a few minutes to write this 
> > >>>>>>>>> email to you.
> > >>>>>>>>> 
> > >>>>>>>>> What follows is an example of the problem on a small SBC (Nano Pi 
> > >>>>>>>>> NEO Air - 
> > >>>>>>>>> https://www.friendlyarm.com/index.php?route=product/product&product_id=151),
> > >>>>>>>>>  although I have reproduced this issue on some 64-bit ARM A53 
> > >>>>>>>>> boards as well (e.g., w/1GB RAM, including the Nano Pi NEO2, NEO2 
> > >>>>>>>>> Black, etc.)  I have not tried zstd on an amd64 machine yet.
> > >>>>>>>>> 
> > >>>>>>>>> This filesystem is formatted with compression ("-O 
> > >>>>>>>>> extra_attr,enable_compression"), and mounted to use zstd 
> > >>>>>>>>> compression ("-o compress_algorithm=zstd"), and the root mount 
> > >>>>>>>>> directory has compression enabled ("chattr +c mntpt").  After 
> > >>>>>>>>> doing a simple test copy of a number of files to it, it started 
> > >>>>>>>>> giving page allocation failures - example traps are provided 
> > >>>>>>>>> below.
> > >>>>>>>>> 
> > >>>>>>>>> I'm not sure if there are some kernel memory parameters that need 
> > >>>>>>>>> to be changed or something, but even so it seems to me that this 
> > >>>>>>>>> sort of thing shouldn't happen by default by a filesystem :-)  
> > >>>>>>>>> Here are a couple of example failure cases, running on stable 
> > >>>>>>>>> kernel 5.8.3:
> > >>>>>>>>> 
> > >>>>>>>>> [168053.070957] F2FS-fs (mmcblk0p1): Found nat_bits in checkpoint 
> > >>>>>>>>> [168053.742204] F2FS-fs (mmcblk0p1): Mounted with checkpoint 
> > >>>>>>>>> version = 37a48fb3
> > >>>>>>>>> [168170.268522] kworker/u8:1: page allocation failure: order:6, 
> > >>>>>>>>> mode:0x40c40(GFP_NOFS|__GFP_COMP), 
> > >>>>>>>>> nodemask=(null),cpuset=/,mems_allowed=0
> > >>>>>>>>> [168170.268556] CPU: 3 PID: 7830 Comm: kworker/u8:1 Tainted: G    
> > >>>>>>>>>      C        5.8.3-sunxi #trunk
> > >>>>>>>>> [168170.268559] Hardware name: Allwinner sun8i Family
> > >>>>>>>>> [168170.268580] Workqueue: writeback wb_workfn (flush-179:24)
> > >>>>>>>>> [168170.268611] [<c010d6d5>] (unwind_backtrace) from [<c0109a55>] 
> > >>>>>>>>> (show_stack+0x11/0x14)
> > >>>>>>>>> [168170.268624] [<c0109a55>] (show_stack) from [<c056d489>] 
> > >>>>>>>>> (dump_stack+0x75/0x84)
> > >>>>>>>>> [168170.268639] [<c056d489>] (dump_stack) from [<c0243b53>] 
> > >>>>>>>>> (warn_alloc+0xa3/0x104)
> > >>>>>>>>> [168170.268651] [<c0243b53>] (warn_alloc) from [<c024473b>] 
> > >>>>>>>>> (__alloc_pages_nodemask+0xb87/0xc40)
> > >>>>>>>>> [168170.268662] [<c024473b>] (__alloc_pages_nodemask) from 
> > >>>>>>>>> [<c02267c5>] (kmalloc_order+0x19/0x38)
> > >>>>>>>>> [168170.268672] [<c02267c5>] (kmalloc_order) from [<c02267fd>] 
> > >>>>>>>>> (kmalloc_order_trace+0x19/0x90)
> > >>>>>>>>> [168170.268685] [<c02267fd>] (kmalloc_order_trace) from 
> > >>>>>>>>> [<c047c805>] (zstd_init_compress_ctx+0x51/0xfc)
> > >>>>>>>>> [168170.268697] [<c047c805>] (zstd_init_compress_ctx) from 
> > >>>>>>>>> [<c047e2bd>] (f2fs_write_multi_pages+0x269/0x68c)
> > >>>>>>>>> [168170.268708] [<c047e2bd>] (f2fs_write_multi_pages) from 
> > >>>>>>>>> [<c0465163>] (f2fs_write_cache_pages+0x3bf/0x538)
> > >>>>>>>>> [168170.268718] [<c0465163>] (f2fs_write_cache_pages) from 
> > >>>>>>>>> [<c046550f>] (f2fs_write_data_pages+0x233/0x264)
> > >>>>>>>>> [168170.268730] [<c046550f>] (f2fs_write_data_pages) from 
> > >>>>>>>>> [<c0210db5>] (do_writepages+0x35/0x98)
> > >>>>>>>>> [168170.268745] [<c0210db5>] (do_writepages) from [<c0290c17>] 
> > >>>>>>>>> (__writeback_single_inode+0x2f/0x358)
> > >>>>>>>>> [168170.268757] [<c0290c17>] (__writeback_single_inode) from 
> > >>>>>>>>> [<c02910c5>] (writeback_sb_inodes+0x185/0x378)
> > >>>>>>>>> [168170.268766] [<c02910c5>] (writeback_sb_inodes) from 
> > >>>>>>>>> [<c02912e9>] (__writeback_inodes_wb+0x31/0x88)
> > >>>>>>>>> [168170.268776] [<c02912e9>] (__writeback_inodes_wb) from 
> > >>>>>>>>> [<c0291533>] (wb_writeback+0x1f3/0x264)
> > >>>>>>>>> [168170.268783] [<c0291533>] (wb_writeback) from [<c0292429>] 
> > >>>>>>>>> (wb_workfn+0x24d/0x3a4)
> > >>>>>>>>> [168170.268794] [<c0292429>] (wb_workfn) from [<c0130b2f>] 
> > >>>>>>>>> (process_one_work+0x15f/0x3b0)
> > >>>>>>>>> [168170.268803] [<c0130b2f>] (process_one_work) from [<c0130e7b>] 
> > >>>>>>>>> (worker_thread+0xfb/0x3e0)
> > >>>>>>>>> [168170.268813] [<c0130e7b>] (worker_thread) from [<c0135c3b>] 
> > >>>>>>>>> (kthread+0xeb/0x10c)
> > >>>>>>>>> [168170.268824] [<c0135c3b>] (kthread) from [<c0100159>] 
> > >>>>>>>>> (ret_from_fork+0x11/0x38)
> > >>>>>>>>> [168170.268829] Exception stack(0xccb67fb0 to 0xccb67ff8)
> > >>>>>>>>> [168170.268835] 7fa0:                                     
> > >>>>>>>>> 00000000 00000000 00000000 00000000
> > >>>>>>>>> [168170.268842] 7fc0: 00000000 00000000 00000000 00000000 
> > >>>>>>>>> 00000000 00000000 00000000 00000000
> > >>>>>>>>> [168170.268848] 7fe0: 00000000 00000000 00000000 00000000 
> > >>>>>>>>> 00000013 00000000
> > >>>>>>>>> [168170.268853] Mem-Info:
> > >>>>>>>>> [168170.268867] active_anon:2089 inactive_anon:5866 
> > >>>>>>>>> isolated_anon:0
> > >>>>>>>>>                  active_file:41402 inactive_file:37715 
> > >>>>>>>>> isolated_file:0
> > >>>>>>>>>                  unevictable:4 dirty:9162 writeback:90
> > >>>>>>>>>                  slab_reclaimable:5935 slab_unreclaimable:10851
> > >>>>>>>>>                  mapped:4694 shmem:881 pagetables:369 bounce:0
> > >>>>>>>>>                  free:12678 free_pcp:201 free_cma:11324
> > >>>>>>>>> [168170.268877] Node 0 active_anon:8356kB inactive_anon:23464kB 
> > >>>>>>>>> active_file:165608kB inactive_file:150860kB unevictable:16kB 
> > >>>>>>>>> isolated(anon):0kB isolated(file):0kB mapped:18776kB 
> > >>>>>>>>> dirty:36648kB writeback:360kB shmem:3524kB writeback_tmp:0kB 
> > >>>>>>>>> all_unreclaimable? no
> > >>>>>>>>> [168170.268891] Normal free:50712kB min:6500kB low:7100kB 
> > >>>>>>>>> high:7700kB reserved_highatomic:0KB active_anon:8356kB 
> > >>>>>>>>> inactive_anon:23464kB active_file:165764kB inactive_file:150884kB 
> > >>>>>>>>> unevictable:16kB writepending:36944kB present:524288kB 
> > >>>>>>>>> managed:503888kB mlocked:16kB kernel_stack:1144kB 
> > >>>>>>>>> pagetables:1476kB bounce:0kB free_pcp:828kB local_pcp:116kB 
> > >>>>>>>>> free_cma:45296kB
> > >>>>>>>>> [168170.268893] lowmem_reserve[]: 0 0 0
> > >>>>>>>>> [168170.268899] Normal: 1096*4kB (UMEC) 217*8kB (UMEC) 132*16kB 
> > >>>>>>>>> (UMEC) 82*32kB (UMEC) 283*64kB (UC) 72*128kB (C) 16*256kB (UC) 
> > >>>>>>>>> 9*512kB (UC) 4*1024kB (C) 0*2048kB 0*4096kB = 50984kB
> > >>>>>>>>> [168170.268927] 80105 total pagecache pages
> > >>>>>>>>> [168170.268933] 72 pages in swap cache
> > >>>>>>>>> [168170.268937] Swap cache stats: add 5255, delete 5182, find 
> > >>>>>>>>> 5492/6131
> > >>>>>>>>> [168170.268939] Free swap  = 232484kB
> > >>>>>>>>> [168170.268941] Total swap = 251940kB
> > >>>>>>>>> [168170.268944] 131072 pages RAM
> > >>>>>>>>> [168170.268946] 0 pages HighMem/MovableOnly
> > >>>>>>>>> [168170.268948] 5100 pages reserved
> > >>>>>>>>> [168170.268951] 32768 pages cma reserved
> > >>>>>>>>> [168182.775001] warn_alloc: 84 callbacks suppressed
> > >>>>>>>>> [168182.775115] kworker/u9:3: page allocation failure: order:9, 
> > >>>>>>>>> mode:0x40c40(GFP_NOFS|__GFP_COMP), 
> > >>>>>>>>> nodemask=(null),cpuset=/,mems_allowed=0 
> > >>>>>>>>> [168182.775235] CPU: 3 PID: 8168 Comm: kworker/u9:3 Tainted: G    
> > >>>>>>>>>      C        5.8.3-sunxi #trunk
> > >>>>>>>>> [168182.775246] Hardware name: Allwinner sun8i Family
> > >>>>>>>>> [168182.775367] Workqueue: f2fs_post_read_wq f2fs_post_read_work
> > >>>>>>>>> [168182.775534] [<c010d6d5>] (unwind_backtrace) from [<c0109a55>] 
> > >>>>>>>>> (show_stack+0x11/0x14)
> > >>>>>>>>> [168182.775584] [<c0109a55>] (show_stack) from [<c056d489>] 
> > >>>>>>>>> (dump_stack+0x75/0x84)
> > >>>>>>>>> [168182.775658] [<c056d489>] (dump_stack) from [<c0243b53>] 
> > >>>>>>>>> (warn_alloc+0xa3/0x104)
> > >>>>>>>>> [168182.775689] [<c0243b53>] (warn_alloc) from [<c024473b>] 
> > >>>>>>>>> (__alloc_pages_nodemask+0xb87/0xc40)
> > >>>>>>>>> [168182.775731] [<c024473b>] (__alloc_pages_nodemask) from 
> > >>>>>>>>> [<c02267c5>] (kmalloc_order+0x19/0x38)
> > >>>>>>>>> [168182.775757] [<c02267c5>] (kmalloc_order) from [<c02267fd>] 
> > >>>>>>>>> (kmalloc_order_trace+0x19/0x90)
> > >>>>>>>>> [168182.775797] [<c02267fd>] (kmalloc_order_trace) from 
> > >>>>>>>>> [<c047c665>] (zstd_init_decompress_ctx+0x21/0x88)
> > >>>>>>>>> [168182.775837] [<c047c665>] (zstd_init_decompress_ctx) from 
> > >>>>>>>>> [<c047e9cf>] (f2fs_decompress_pages+0x97/0x228)
> > >>>>>>>>> [168182.775860] [<c047e9cf>] (f2fs_decompress_pages) from 
> > >>>>>>>>> [<c045d0ab>] (__read_end_io+0xfb/0x130)
> > >>>>>>>>> [168182.775871] [<c045d0ab>] (__read_end_io) from [<c045d141>] 
> > >>>>>>>>> (f2fs_post_read_work+0x61/0x84)
> > >>>>>>>>> [168182.775884] [<c045d141>] (f2fs_post_read_work) from 
> > >>>>>>>>> [<c0130b2f>] (process_one_work+0x15f/0x3b0)
> > >>>>>>>>> [168182.775893] [<c0130b2f>] (process_one_work) from [<c0130e7b>] 
> > >>>>>>>>> (worker_thread+0xfb/0x3e0)
> > >>>>>>>>> [168182.775905] [<c0130e7b>] (worker_thread) from [<c0135c3b>] 
> > >>>>>>>>> (kthread+0xeb/0x10c)
> > >>>>>>>>> [168182.775919] [<c0135c3b>] (kthread) from [<c0100159>] 
> > >>>>>>>>> (ret_from_fork+0x11/0x38)
> > >>>>>>>>> [168182.775924] Exception stack(0xcfd5ffb0 to 0xcfd5fff8)
> > >>>>>>>>> [168182.775930] ffa0:                                     
> > >>>>>>>>> 00000000 00000000 00000000 00000000
> > >>>>>>>>> [168182.775937] ffc0: 00000000 00000000 00000000 00000000 
> > >>>>>>>>> 00000000 00000000 00000000 00000000
> > >>>>>>>>> [168182.775943] ffe0: 00000000 00000000 00000000 00000000 
> > >>>>>>>>> 00000013 00000000
> > >>>>>>>>> [168182.775949] Mem-Info:
> > >>>>>>>>> [168182.775968] active_anon:2361 inactive_anon:4620 
> > >>>>>>>>> isolated_anon:0
> > >>>>>>>>>                  active_file:16267 inactive_file:15209 
> > >>>>>>>>> isolated_file:0
> > >>>>>>>>>                  unevictable:4 dirty:3287 writeback:0
> > >>>>>>>>>                  slab_reclaimable:5976 slab_unreclaimable:11441
> > >>>>>>>>>                  mapped:3760 shmem:485 pagetables:396 bounce:0
> > >>>>>>>>>                  free:60170 free_pcp:71 free_cma:25015
> > >>>>>>>>> [168182.775980] Node 0 active_anon:9444kB inactive_anon:18480kB 
> > >>>>>>>>> active_file:65068kB inactive_file:60836kB unevictable:16kB 
> > >>>>>>>>> isolated(anon):0kB isolated(file):0kB mapped:15040kB 
> > >>>>>>>>> dirty:13148kB writeback:0kB shmem:1940kB writeback_tmp:0kB 
> > >>>>>>>>> all_unreclaimable? no
> > >>>>>>>>> [168182.775995] Normal free:240680kB min:2404kB low:3004kB 
> > >>>>>>>>> high:3604kB reserved_highatomic:0KB active_anon:9444kB 
> > >>>>>>>>> inactive_anon:18480kB active_file:65068kB inactive_file:60836kB 
> > >>>>>>>>> unevictable:16kB writepending:13112kB present:524288kB 
> > >>>>>>>>> managed:503888kB mlocked:16kB kernel_stack:1168kB 
> > >>>>>>>>> pagetables:1584kB bounce:0kB free_pcp:280kB local_pcp:16kB 
> > >>>>>>>>> free_cma:100060kB
> > >>>>>>>>> [168182.775996] lowmem_reserve[]: 0 0 0
> > >>>>>>>>> [168182.776003] Normal: 4668*4kB (UMEC) 4945*8kB (UMEC) 3001*16kB 
> > >>>>>>>>> (UEC) 1684*32kB (UMEC) 584*64kB (UMEC) 157*128kB (UMEC) 39*256kB 
> > >>>>>>>>> (UMEC) 12*512kB (UMC) 7*1024kB (UMC) 0*2048kB 0*4096kB = 240904kB
> > >>>>>>>>> [168182.776032] 32082 total pagecache pages
> > >>>>>>>>> [168182.776039] 66 pages in swap cache
> > >>>>>>>>> [168182.776043] Swap cache stats: add 6730, delete 6663, find 
> > >>>>>>>>> 5492/6140
> > >>>>>>>>> [168182.776045] Free swap  = 227108kB
> > >>>>>>>>> [168182.776047] Total swap = 251940kB
> > >>>>>>>>> [168182.776050] 131072 pages RAM
> > >>>>>>>>> [168182.776052] 0 pages HighMem/MovableOnly
> > >>>>>>>>> [168182.776054] 5100 pages reserved
> > >>>>>>>>> [168182.776056] 32768 pages cma reserved
> > >>>>>>>>> 
> > >>>>>>>>> Again, I've had no issues on any of my boards when using lz4 
> > >>>>>>>>> compression, only with zstd.  (I have not had an opportunity to 
> > >>>>>>>>> try lzo-rle yet.)  I'm happy to try to provide more information 
> > >>>>>>>>> if necessary.  Thanks!
> > >>>>>>>>> 
> > >>>>>>>>> 
> > >>>>>>>> 
> > >>>>>> 
> > >>>> 
> > >> 
> > > 
>


_______________________________________________
Linux-f2fs-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

Reply via email to