Thank you for the response Johannes. I’ll test this and get back with the results. Also, I should mention - Holger have suggested to enable LRU and this also seems to be helping with this issue, but still I thought I should report it when it’s not enabled. I’ll see if compaction helps and let you know if it helped. Regards, Damian. > Wiadomość napisana przez Johannes Weiner <hannes@xxxxxxxxxxx> w dniu 25 wrz 2024, o godz. 19:20: > > Hi Damian, > > On Tue, Sep 24, 2024 at 10:52:28PM +0200, Damian Dudycz wrote: >> I'm running Gentoo on the PlayStation 3 console (PPC64BE CPU), using custom >> firmware (OtherOS++) feature. >> >> Upgrading from 6.6 to 6.10, I have noticed that OOM kills started during long >> and intense processes, like compiling code or extracting a large archive. >> >> The OOM usually occurs after about 10-20 minutes of for example >> compiling the gentoo-kernel package. > > Thanks for your excellent and detailed report, and sorry about the > breakage. > > While going through the dmesg, I'm noticing the following: > > [ 719.989545] configure invoked oom-killer: gfp_mask=0x400dc0(GFP_KERNEL_ACCOUNT|__GFP_ZERO), order=2, oom_score_adj=0 > [ 719.989607] COMPACTION is disabled!!! > [ 719.989633] CPU: 1 PID: 4701 Comm: configure Not tainted 6.9.0-rc4-test-00116-gc0cd6f557b90-dirty #1 > [ 719.989665] Hardware name: SonyPS3 Cell Broadband Engine 0x702100 PS3 > [ 719.989688] Call Trace: > [ 719.989708] [c00000000a5834a0] [c000000000662e9c] .dump_stack_lvl+0xb0/0x100 (unreliable) > [ 719.989777] [c00000000a583530] [c00000000013e43c] .dump_header+0x5c/0x414 > [ 719.989835] [c00000000a583600] [c00000000013ec38] .oom_kill_process+0xcc/0x598 > [ 719.989888] [c00000000a5836f0] [c00000000013f6f0] .out_of_memory+0x3d0/0x3f0 > [ 719.989939] [c00000000a5837a0] [c00000000018f28c] .__alloc_pages_slowpath.constprop.0+0x540/0x6b0 > [ 719.989987] [c00000000a5838f0] [c00000000018f4f4] .__alloc_pages_noprof+0xf8/0x1c0 > [ 719.990031] [c00000000a5839c0] [c0000000000505d0] .copy_process+0x1d4/0x1bf0 > [ 719.990085] [c00000000a583b40] [c000000000052144] .kernel_clone+0xcc/0x3f0 > [ 719.990136] [c00000000a583c50] [c0000000000524d4] .__do_sys_clone+0x6c/0x90 > [ 719.990188] [c00000000a583d80] [c00000000001f600] .system_call_exception+0x1f4/0x260 > [ 719.990246] [c00000000a583e10] [c00000000000b2d4] system_call_common+0xf4/0x258 > > This is clone() trying to allocate a thread stack, which is a request > for 4 physically contiguous pages (order=2 -> 2^2 pages). > > The second line warns that you don't have CONFIG_COMPACTION enabled, > which is the kernel's facility to assemble such contiguous page > blocks. (God bless you, Michal Hocko, for adding this warning.) > > This is not a common configuration anymore, as we have since removed > various other mechanisms from the MM code to support higher order > allocations. So I think you may have gotten lucky in the past. > > Can you please try with CONFIG_COMPACTION=y? > > [ I think what likely happened is that, before my patch, an unmovable > request falling back to a movable block would have stolen the rest > of its free pages even if it hadn't claimed the block as unmovable. > Now it doesn't anymore, and the block, already dominated by cache > and anon, will continue to fill up with cache and anon. Not an issue > with compaction - and better for long-term defragmentation > prospects; but without compaction, you just get a bit less lucky > specifically with those higher-order kernel requests. ] > > Thanks
