From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8464DC77B75 for ; Tue, 23 May 2023 07:10:07 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BFA706B0075; Tue, 23 May 2023 03:10:06 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BAA796B0078; Tue, 23 May 2023 03:10:06 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A71AE900003; Tue, 23 May 2023 03:10:06 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 961786B0075 for ; Tue, 23 May 2023 03:10:06 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 3DE2816069E for ; Tue, 23 May 2023 07:10:05 +0000 (UTC) X-FDA: 80820645570.23.3534AF8 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf03.hostedemail.com (Postfix) with ESMTP id 6BA3020019 for ; Tue, 23 May 2023 07:10:02 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=tGEyugzO; spf=pass (imf03.hostedemail.com: domain of rppt@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=rppt@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1684825802; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=qIEqIXy3uUkgJQcI6SJaGQhGW0EIwUessaIX4Ah8qdI=; b=rCtfiCJnNiSnbxjOPG78XNUalKSRXlOuuRdz2bPVITL0ciphsGEtWlbIRHRZ8PUTDF+JUZ v7g0BrOgDFytoUZ7LpHrNUgiBbxPyCRIvNTNwzKqZyrVj6d9d4SxE3qAT3m53vv6PucMBn wA9RaSxHdLRsH4vIPYVMDvwm4ZV3WFs= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=tGEyugzO; spf=pass (imf03.hostedemail.com: domain of rppt@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=rppt@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1684825802; a=rsa-sha256; cv=none; b=qz5+rlUu2/kpOgfyhLvYWo19cfe4XsSGx3kt+LslrtMrRn8sQF4cYuLd87AlKcqfBwbioO JoRuhnd7w5KjMUohsCB7YtlXgrIwDUhnr0RpLPodqMbPKO1BQpsGcF+diGFiKKMKeV0tGv SJVtiOMKQAQO21gDlwW+FEZpu3fkKZ4= Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 5D5806247A; Tue, 23 May 2023 07:10:01 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B72E6C433EF; Tue, 23 May 2023 07:09:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1684825800; bh=hQ2tcliwYeQM50kx394PH5dz7F8OEq4HXUPTtEYAACg=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=tGEyugzO88lJKj43JyaezQHvpvzQACU5cgXKFPuqASi7x60/2eUfCZLFO6CapNKsx tiyFMPfRN4ipscRJCGKB9n6nKwEyAwcnTJ1kXNpAbAwJuEUQ6+GXE0k4PQ0r5141Lk 6/zwY5n7sGp33GWhQ0OXmOThpmjVX3NYFzCv8F1ce3dTQzU3tl+TzD4LRragjxqnH4 tQOWyvSwJYVPUZC7OMNizUP1mq7f2h+LHl4JIGXOACVfOM8ShTJbGGrREkHQxssh/N Do9NDxV8VbrMfh6K1pTlC1w8xZH8y62+c8hPBJETnFIrZWwcs8+N90W3rBaXXfzxWt pNfpxnCtw4mdQ== Date: Tue, 23 May 2023 10:09:55 +0300 From: Mike Rapoport To: "Pratoussy, Martin (GE Vernova)" Cc: "Kurtz, Florian (GE Vernova)" , linux-mm@kvack.org Subject: Re: EXT: Re: Disabling CONFIG_COMPACTION Message-ID: References: <20230517100220.GB4967@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspamd-Queue-Id: 6BA3020019 X-Rspam-User: X-Stat-Signature: 1x7ugt7do4sh1mbk1jtuaohrde11ssb9 X-Rspamd-Server: rspam01 X-HE-Tag: 1684825802-572981 X-HE-Meta: U2FsdGVkX18syBn0j53Z8tkogfZoFZST2v5UCBgfSKF33sllS6829lv401A7TjPwMMqx5hyrSYpMXl/OlEQvLMnBuUGeW+VVSHJHWLJ3tkWvNztH3Q1TUoyxIi7mwq1r0+gVpvWrtAdhnYqbFOzDkhCJ0rq9jUrYFVzvlImDjQ9g916nA5mIEoqaHi1KZiIMPhEGmQhy+vqpv4IYFYQKQ6N0316okkCe1g+pMPd0hXAQZOSSb4ajbKEr6ffI0/oStNP49zMdWDV9uwdWCEGW5DwfCY0s7vAwnx99z+OOY1lSZzH5NW0OZrQXW9LpQGjxH67TUz/sP5fhTF10uWvpOkqlcznu0wuWtkMdDFbomK1qEvFDAxuFGBKaPCRhT1LjKQzX3QvhkJjh+RchBWtkOw/jUy9+1T2g4qBNU1KBezhO/0ATF7J16b5vHYEXlM4T9a4Cckqm6dPUlQDtAjhs8VGMRP3FWNTEKa7ljfVvLiby6TzuJbRI/70mc9ibaWVQu09NLorY0BLqh2j6HsYbUHLwVk+k/XOJCzFRn7wBC9lT/Kx1rgfKMzTbWyE86m4S462MNMX6etuBGvp+omPniDP+mWQ9hbRy2rPEPztvtBEB+4PAlWMz2sumgcjs8uaOPvR8w4HEUmP3FZIEaRTupkOs1gEI6GNfxMbIllj3Y2QqDFxYH6jlO/N2LgAJ37w+MWAQCEzl5LgirmQqB6aBviQ6AKvWIhLmlut4qFC+lI+78ibFixKO3fzeJ4dC0IiyLw59Z/axqTfwKPrcnx13faQ2cJqy+7YZQtxjyRNBF2BCi3jlbty/gLvdYI0v4e7XOsEundg2wCmeosKuTlRVWew2j0idwDR6T4p0BEj8kyas8gtNlHdUVyrRXeba0CWC7cAN+E247ezI823nKz657aYIwVMjo/9eC9YNokOi0hPdItiX0kEhGGVFqreoT9rr6TQiRfVQyGv5ce/gXeD 5nAEH5tR Ha5MbrsuNSgUdrFi0BZ2SAkNzCseTWchBNG6L90/qPe4+WpEC8IRzXbA6FFOYCncH9i05yfGvOtdGT3t6x75b7NkphZfnx3kt+77eMSuGZc2OutrR+DmCnYQ731kwPkkkXxJTwXyK2cfoMBB4pSQ8ZuKRHeOTc0Yg7EkhWUoOdUv1Uhi6KNp6TApwqEVP/lDr+KFfMtY8hpWaNi/moyGT73r+hGZOS0LLv6m2/pdyMlmFJeHX8LKSQmvrXq2M+oRFVIu9eo1tp5A1mYyl34fQrCSGxhLY7J7l3cxiushYPBbeOPQJw7PvA7qVYroT89gvvg/6xvXbhWCK5VI4RcgWtpVn/HqYCNIoGHcNR6mEdwjR/zkEy3BxBUhutbCR2w3eraa3GgzRFgSNBHWBqtq7Zm1fpuyglY8gG70XJNNpkStMYgKcX+hB7w8eQtvcEjGSaXN8PLXbGMhWEnfMLpxZlhx4vQ7ujUbYLmw4tp4aDITOowGzlO3Za5Scy9QWkQO3qG0fRLXhh7rQpZO75IgLFYYbPH5fBXCUbGl8o/Kt0hM+HyPX1v3TK4aHUQDeMMAEmZwI X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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 > Envoyé : mercredi 17 mai 2023 12:02 > À : Pratoussy, Martin (GE Vernova) > Cc : linux-mm@kvack.org; Kurtz, Florian (GE Vernova) > 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.