Re: [PATCH net] net: atlantic: keep rings across suspend/resume

[Lorenz Brun <lorenz@brun.one>]

Am Do, 12. Dez 2024 um 18:20:26 +01:00:00 schrieb Andrew Lunn 
<andrew@lunn.ch>:
> On Thu, Dec 12, 2024 at 03:39:24AM +0100, Lorenz Brun wrote:
>>  The rings are order-6 allocations which tend to fail on suspend due 
>> to
>>  fragmentation. As memory is kept during suspend/resume, we don't 
>> need to
>>  reallocate them.
> 
> I don't know this driver. Are there other reasons to reallocate the
> rings? Change of MTU? ethtool settings? If they are also potentially
> going to run into memory fragmentation issues, maybe it would be
> better to use smaller order allocations, or vmalloc, if the hardware
> supports that, etc.
> 
> 	Andrew

ethtool settings do indeed reallocate, but not during unsuspend where 
we have GFP_NOIO. Smaller oder allocations would definitely be better, 
but on systems without IOMMU that would probably pose a problem as 
rings are generally assumed to be contigous by hardware (as far as I 
understand). I don't have access to hardware docs, so I don't know if 
you can make the HW work without physically-contiguous memory.

Linux just really doesn't handle high-order allocations well, I got one 
unsuspend failure with 6GiB (!!) of free space in the relevant region 
(but no order-6 or higher). I have no idea why it doesn't defragment 
before failing the allocation as it clearly has enough memory.

kworker/u97:14: page allocation failure: order:6, 
mode:0x40d00(GFP_NOIO|__GFP_COMP|__GFP_ZERO), 
nodemask=(null),cpuset=/,mems_allowed=0
Node 0 Normal: 787628*4kB (UME) 234026*8kB (UME) 50882*16kB (UME) 
13751*32kB (UME) 35*64kB (UME) 9*128kB (M) 0*256kB 0*512kB 0*1024kB 
1*2048kB (H) 0*4096kB = 6282304kB


Regards,
Lorenz