kswapd0: page allocation failure: order:0, mode:0x820(GFP_ATOMIC), nodemask=(null),cpuset=/,mems_allowed=0 (Kernel v6.5.9, 32bit ppc)

[Chengming Zhou]

On 2024/6/6 13:43, Sergey Senozhatsky wrote:
> On (24/06/06 12:46), Chengming Zhou wrote:
>>>> Agree, I think we should try to improve locking scalability of zsmalloc.
>>>> I have some thoughts to share, no code or test data yet:
>>>>
>>>> 1. First, we can change the pool global lock to per-class lock, which
>>>>    is more fine-grained.
>>>
>>> Commit c0547d0b6a4b6 "zsmalloc: consolidate zs_pool's migrate_lock
>>> and size_class's locks" [1] claimed no significant difference
>>> between class->lock and pool->lock.
>>
>> Ok, I haven't looked into the history much, that seems preparation of trying
>> to introduce reclaim in the zsmalloc? Not sure. But now with the reclaim code
>> in zsmalloc has gone, should we change back to the per-class lock? Which is
> 
> Well, the point that commit made was that Nhat (and Johannes?) were
> unable to detect any impact of pool->lock on a variety of cases.  So
> we went on with code simplification.

Right, the code is simpler.

> 
>> obviously more fine-grained than the pool lock. Actually, I have just done it,
>> will test to get some data later.
> 
> Thanks, we'll need data on this.  I'm happy to take the patch, but
> jumping back and forth between class->lock and pool->lock merely
> "for obvious reasons" is not what I'm extremely excited about.

Yeah, agree, we need test data.