https://bugzilla.kernel.org/show_bug.cgi?id=217965 Bug ID: 217965 Summary: ext4(?) regression since 6.5.0 on sata hdd Product: File System Version: 2.5 Hardware: All OS: Linux Status: NEW Severity: normal Priority: P3 Component: ext4 Assignee: fs_ext4@xxxxxxxxxxxxxxxxxxxx Reporter: iivanich@xxxxxxxxx Regression: No Since kernel 6.5.x and 6.6-rc* I'm getting weird kworker flush activity when building openwrt from sources. 91 root 20 0 0 0 0 R 99,7 0,0 18:06.57 kworker/u16:4+flush-8:16 Openwrt sources resides on the sata hdd drive with ext4 fs,I'm using this setup for a last 5 years, the problem is that since 6.5 kernels after the openwrt kernel patch make step(https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=scripts/patch-kernel.sh;h=c2b7e7204952f93946a6075d546cbeae32c2627f;hb=HEAD which probably involves a lot of copy and write operations) kworker/u16:4+flush-8:16 uses 100% of one core for a while(5-15 minutes) even after I canceling openwrt build. I tried to move this openwrt sources folder to an ssd drive where my system is resides and run openwrt build from there and getting no issues with kworker flush cpu usage. Also I have no such behavior with 6.4.x and older kernels so it looks like regression to me, not sure if this is a fs, vfs or even block subsystem issue. This is how it looks in perf Samples: 320K of event 'cycles:P', Event count (approx.): 363448649248 Children Self Command Shared Object Symbol + 12,40% 0,00% kworker/u16:2+f [kernel.vmlinux] [k] ret_from_fork_asm + 12,40% 0,00% kworker/u16:2+f [kernel.vmlinux] [k] ret_from_fork + 12,40% 0,00% kworker/u16:2+f [kernel.vmlinux] [k] kthread + 12,40% 0,00% kworker/u16:2+f [kernel.vmlinux] [k] worker_thread + 12,40% 0,00% kworker/u16:2+f [kernel.vmlinux] [k] process_one_work + 12,40% 0,00% kworker/u16:2+f [kernel.vmlinux] [k] wb_workfn + 12,40% 0,00% kworker/u16:2+f [kernel.vmlinux] [k] wb_writeback + 12,40% 0,00% kworker/u16:2+f [kernel.vmlinux] [k] __writeback_inodes_wb + 12,40% 0,00% kworker/u16:2+f [kernel.vmlinux] [k] writeback_sb_inodes + 12,40% 0,00% kworker/u16:2+f [kernel.vmlinux] [k] __writeback_single_inode + 12,40% 0,00% kworker/u16:2+f [kernel.vmlinux] [k] do_writepages + 12,40% 0,00% kworker/u16:2+f [kernel.vmlinux] [k] ext4_writepages + 12,40% 0,00% kworker/u16:2+f [kernel.vmlinux] [k] ext4_do_writepages + 12,39% 0,00% kworker/u16:2+f [kernel.vmlinux] [k] ext4_map_blocks + 12,39% 0,00% kworker/u16:2+f [kernel.vmlinux] [k] ext4_ext_map_blocks + 12,38% 0,00% kworker/u16:2+f [kernel.vmlinux] [k] ext4_mb_new_blocks + 12,38% 0,93% kworker/u16:2+f [kernel.vmlinux] [k] ext4_mb_regular_allocator + 9,42% 0,00% cc1 [unknown] [.] 0000000000000000 + 5,42% 0,53% kworker/u16:2+f [kernel.vmlinux] [k] ext4_mb_scan_aligned + 4,88% 0,69% kworker/u16:2+f [kernel.vmlinux] [k] mb_find_extent + 3,99% 3,95% kworker/u16:2+f [kernel.vmlinux] [k] mb_find_order_for_block + 3,51% 0,61% kworker/u16:2+f [kernel.vmlinux] [k] ext4_mb_load_buddy_gfp + 2,95% 0,01% cc1 [kernel.vmlinux] [k] asm_exc_page_fault + 2,67% 0,18% kworker/u16:2+f [kernel.vmlinux] [k] pagecache_get_page + 2,41% 0,40% kworker/u16:2+f [kernel.vmlinux] [k] __filemap_get_folio + 2,33% 2,10% cc1 cc1 [.] cpp_get_token_1 + 2,12% 0,05% cc1 [kernel.vmlinux] [k] exc_page_fault + 2,07% 0,04% cc1 [kernel.vmlinux] [k] do_user_addr_fault + 1,81% 0,52% kworker/u16:2+f [kernel.vmlinux] [k] filemap_get_entry 1,80% 1,71% cc1 cc1 [.] ht_lookup_with_hash + 1,77% 0,08% cc1 [kernel.vmlinux] [k] handle_mm_fault + 1,65% 0,14% cc1 [kernel.vmlinux] [k] __handle_mm_fault 1,60% 1,49% cc1 cc1 [.] _cpp_lex_direct + 1,54% 0,73% kworker/u16:2+f [kernel.vmlinux] [k] ext4_mb_good_group + 1,49% 1,46% cc1 cc1 [.] ggc_internal_alloc + 1,28% 0,05% cc1 [kernel.vmlinux] [k] do_anonymous_page + 1,28% 0,04% cc1 [kernel.vmlinux] [k] entry_SYSCALL_64 -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
