lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <bug-217965-13602-qyI8Zuxh5M@https.bugzilla.kernel.org/> Date: Sun, 07 Jan 2024 02:56:44 +0000 From: bugzilla-daemon@...nel.org To: linux-ext4@...r.kernel.org Subject: [Bug 217965] ext4(?) regression since 6.5.0 on sata hdd https://bugzilla.kernel.org/show_bug.cgi?id=217965 --- Comment #65 from Matthew Stapleton (matthew4196@...il.com) --- I'm not sure if this will be worth looking into, but with the cpu usage problem, I've done some more testing and "perf report --stdio -i perf.data" is showing around 2 to 3 times as much cpu time since the commit that added the CR_BEST_AVAIL_LEN feature: 7e170922f06bf . With /sys/fs/ext4/<dev>/mb_best_avail_max_trim_order set to 0 it goes a bit lower, but is still at least 2 times cpu. With perf record -ag sleep 25 which is the time it takes the extract to run, it's goes from about 2% to 5% so fairly small, but when measuring with 5 second intervals this can go from around 5% to 15%. This cpu usage is concentrated in ext4_get_group_desc and ext4_get_group_info and within these functions, perf is picking up more cpu time in __rcu_read_lock and __rcu_read_unlock. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
Powered by blists - more mailing lists