Hi Martin, Please don't top-post when replying to Linux mailing lists and don't drop cc to the list. On Mon, May 22, 2023 at 09:10:09AM +0000, Pratoussy, Martin (GE Vernova) wrote: > Hello, > > That solution feels weird to me. Isn't compaction supposed to optimize > RAM size when the system is running out of memory by gathering fragmented > pages at the end of the memory? It should be a valid solution to allocate > huge amount of memory (at the scale of our equipment) if the RAM is > fragmented and running out of available space, right? > > Would it mean that compaction is a process that requires more memory than > there is available in the RAM? The equipment the Linux is working on is > supposed to be continuously turned on for years. Wouldn't there be a risk > of OOM error due to the fragmented nature of the memory after months and > months of allocations? Compaction does allocate memory temporarily and in general it's quite costly. For smaller systems like nios2 with 64M of RAM cost of compaction may outweigh its benefits. The effect of fragmentation and the risk of OOM very much depends on the allocation patterns your system has. Unless your system requires lots of large physically contiguous allocations, the fragmentation won't be an issue. You may try investigating why exactly compaction causes an OOM and where does it fail, but I genuinely doubt compaction would be useful for your usecase. > Best regards, > > Martin Pratoussy > Embedded software engineer apprentice – Electronics & High Voltage Digital, Grid Solutions > GE Renewable > M +33 (0)7 82 54 60 81 > www.gegridsolutions.com > 21, Rue Cyprian | 69100 Villeurbanne | France > > -----Message d'origine----- > De : Mike Rapoport <rppt@xxxxxxxxxx> > Envoyé : mercredi 17 mai 2023 12:02 > À : Pratoussy, Martin (GE Vernova) <Martin.PRATOUSSY@xxxxxx> > Cc : linux-mm@xxxxxxxxx; Kurtz, Florian (GE Vernova) <Florian.Kurtz1@xxxxxx> > Objet : EXT: Re: Disabling CONFIG_COMPACTION > > AVERTISSEMENT: cet email provient de l'extérieur de GE. Veuillez valider l'adresse e-mail de l'expéditeur avant de cliquer sur les liens ou les pièces jointes, car ils risquent de ne pas être sûrs. > > Hi, > > On Mon, May 15, 2023 at 08:44:30AM +0000, Pratoussy, Martin (GE Vernova) wrote: > > Hello, > > > > We are facing an issue regarding Linux kernel 5.10.153. When we try to > > allocate huge amount of memory, we eventually run prematurely out of > > memory. The bug has been discovered as follows: although "free" and > > "top" commands would show 40 MB of free memory, sending a 32 MB file > > through SFTP into RAM cache will lead to an OOM error before finishing > > the transfer. > > It has been noted that the command "echo 1 > /prox/sys/vm/compact_memory" > > leads into the very same behavior of the kernel. Disabling > > CONFIG_COMPACTION is surprisingly resolving the allocation issue and > > we are trying to understand why. > > > > You will find below more information about the error we are facing: > > > > * Architecture: Nios2 > > * Total RAM size: 64 MB > > * Available RAM size when error occurs: ~17MB > > * Error message: "Huh VM_FAULT_OOM leaked out to the #PF handler. Retrying PF" > > > > Would you have any idea of what is happening? > > Even without digging into the actual reason for OOM, it makes perfect sense to disable compaction on your system. > > > You will find attached the .config of our kernel. > > > > Best regards, > > > > Martin Pratoussy -- Sincerely yours, Mike.
