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
