Johannes, I have tested this with compaction enabled and it seems to be working fine now. I think, in that case, this should be enabled in ps3_defconfig by default. As for not having compaction in previous versions - I have been using this for pretty long time and Im pretty sure it used to work fine without it. Still I understand, that it should have been used, just mentioning that it really did work without this before that version. I’ll let ps3_defconfig maintainer know about compaction missing in ps3_defconfig or send patch for that config myself. Thank you all for your help with this. Regards, Damian. > Wiadomość napisana przez Damian Dudycz <damiandudycz@xxxxxxxxx> w dniu 25 wrz 2024, o godz. 19:43: > > 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 >
