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 1D400C25B75 for ; Tue, 4 Jun 2024 02:30:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7C63B6B0092; Mon, 3 Jun 2024 22:30:28 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 74F206B0093; Mon, 3 Jun 2024 22:30:28 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5EF896B0095; Mon, 3 Jun 2024 22:30:28 -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 411AA6B0092 for ; Mon, 3 Jun 2024 22:30:28 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 9638516084C for ; Tue, 4 Jun 2024 02:30:27 +0000 (UTC) X-FDA: 82191627294.02.E114373 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf24.hostedemail.com (Postfix) with ESMTP id DBD3B180015 for ; Tue, 4 Jun 2024 02:30:25 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf24.hostedemail.com: domain of anshuman.khandual@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=anshuman.khandual@arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1717468226; 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; bh=ztaPMr4qYDDrV/55F2poxM/DdHr5MT2UtOigP3oAQzA=; b=VuPtmaAsSvN6Zikz9C/bGQn+YcgIKOzRCPoD8LYPxJjp9YNMOeruxn0p7owX3UJzr1MuMT 3rviLVkyj5VX553Hve8iDrMGy9pjgBluNWH4yXNcz13C2N8K0jeMnTMdnOsYqFvL9T2ZXs Ro6k5+t3Yu7BrfIxfrSNYNCmoORxDhM= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf24.hostedemail.com: domain of anshuman.khandual@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=anshuman.khandual@arm.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1717468226; a=rsa-sha256; cv=none; b=nwWm8FA1y7S8fnYzT47Y+3hMDVLdr/41JspZt73qQEbLETxGma/lLqmsSRBlmJLL6bAH7K xn+metHA8efPtTUG59Cj8fM77fcMP+ao21w8E/dS1RFSpOg3u/kKBQmkoX9Blc+h6U3JGe fjGSNHlL0RTerASXPuciL9MrGoTrM4I= Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 382B41042; Mon, 3 Jun 2024 19:30:49 -0700 (PDT) Received: from [10.162.40.15] (a077893.blr.arm.com [10.162.40.15]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id AC8873F792; Mon, 3 Jun 2024 19:30:21 -0700 (PDT) Message-ID: <1a28fda9-be47-4b03-811b-43498622523f@arm.com> Date: Tue, 4 Jun 2024 08:00:18 +0530 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] vmalloc: Modify the alloc_vmap_area() error message for better diagnostics Content-Language: en-US To: "Christoph Lameter (Ampere)" , Matthew Wilcox Cc: Shubhang Kaushik OS , "ampere-linux-kernel@lists.amperecomputing.com" , Andrew Morton , Uladzislau Rezki , Christoph Hellwig , Lorenzo Stoakes , "linux-mm@kvack.org" , linux-arm-kernel@lists.infradead.org References: <3329c844-509b-8769-01b6-a191b60bee35@linux.com> From: Anshuman Khandual In-Reply-To: <3329c844-509b-8769-01b6-a191b60bee35@linux.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: DBD3B180015 X-Stat-Signature: g171c7wpf7zjn11eyeadpz1s3uhmme6i X-Rspam-User: X-Rspamd-Server: rspam11 X-HE-Tag: 1717468225-764428 X-HE-Meta: U2FsdGVkX18irFVk0zhXPploABvhBd+La62R9ILVP0iqvRWnumqypfv3hO9ehqx3ezbodaLzS+fFkW5D8P07V6KV9maXlo4h9g1N8bA/E/jhdSoZLwvhvJFpRgQ7EEdRHAHlAs+MDiZbV10weJiPWKgMDeNneI3SPIbL0zyP/pXn9nHodfcXFD1/xcYnBrI2snn4u/AzmEqXFEc76CeJI0+zjg4HpO2CBQtn96KDv/DZcGr0jE+QDE/BTksYJ439k90+iIc94voa/Nmcgz1/kY5NDBBkCDsTlLIYFm6kI/WFj/QDbl8PlZDUNsQgDCvTepbO5oWdJnQDFsWm/DBq1Jy8archSYwn/7xVWXk2VMo8v5pqrDeL4s307MnR3xehLZvYYny0YXGEtfl5KKqpCfb/FckqZw2sw1UX2XEGRHVHci1e9xOScBanFURi/7G45R7x/nJdsj9q2u4jaSw+ZWo88l/gbllW5HXfmygfue53yl5xlJFVigCX8w0UkGXbow4XfSuugWYo6SEstnzDXIJqQHNOA77gxmnK32aMwt1h1orgxAdHwZ+ggD0Ga67xIcUPPipS9suYbMwHVWhpTXw7+HmYPIWNjr7Eat7VTyzTmbUe44VmADqyeg5bTz1Ah+p+khYHuj7Kj2s1WJElUzffXGOlxMBI2uo5guIByWu+FNwwIN8iXtO3QhbRouF1FvWNYxtVkAcKtpwtnaEJIn7F03Uv1YVUA3crFv1pILPxz+Df4hWjzwZO88PkwCuTUkwZtsgrdzwVxQlpq1xaEcCBCuFbRaRdNuM0rY++sH1z4gvnD7KZBW3PzWu+mphjm9LTq936/Nup9q36fGJN1MQymUDp0XjdU1372qmOAnTsFSGEsM6v5mQwXQeoqMhe2IYAxDxSVGUBWZKafr+OL0w3xiVczsX6lGJoxZ0GBYcdvfHk63hw5NHpI6gAGLkRVYjz1J39qu65/wtkNjh jj0qJXxe Tm4Q9/CrkPerMojY6j90TnmkLGqzxbpihLwTS0tkH6YSbWpR8TzKZdy+7OIDCMbx8rhzPQ6oCxOp/yJX/gtoKCsscVtY8TUcn69UQI0hbKRPtKAy36axHgDVl5BrA0igQis3Gxf3s9S7PtKGbFPEM2cJ28vKZaNTAuU+2pJX9hws1s0/zCbsnkIUOmk0I3ZvdgRHmVJyciwj196JGlOcVrJEMh+U7VqzKQTWlSXI3OYXEsu7kIvDiscH38YDpwkOtesEVtK+mu0Zd5YRKUIa9ynbDNxn72B5Xcl/2 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: List-Subscribe: List-Unsubscribe: On 6/4/24 05:46, Christoph Lameter (Ampere) wrote: > On Tue, 4 Jun 2024, Matthew Wilcox wrote: > >> On Mon, Jun 03, 2024 at 09:30:54PM +0000, Shubhang Kaushik OS wrote: >>> 'vmap allocation for size %lu failed: use vmalloc= to increase size' >>> The above warning is seen in the kernel functionality for allocation of >>> the restricted virtual memory range till exhaustion. >>> >>> This message is misleading because 'vmalloc=' is not a valid kernel >>> parameter on a number of platforms, in particular it is not supported >>> on arm64. With the update, the output gets modified to include the function >> >> Why not fix arm64? > > Arm64 does not need vmalloc= tuning and the problem is not related to being out of vmalloc space in general. > > This occurs if the virtual range during a vmalloc was restricted and is not available (f.e. if one wants a module to be loaded in optimal branch distance to the kernel text segment and we loaded too many modules). The error message needs to indicate the virtual memory restriction which helps the developer/user to debug the situation and not create a wild goose chase for a kernel parmaeter that does not exist. Agreed, current warning message here is misleading pointing to a non-existent kernel command line parameter on the given platform. This kernel parameter i.e 'vmalloc=' seems to be supported only on the x86 and arm (32) platforms. Should not Documentation/admin-guide/kernel-parameters.txt be updated as well making this bit clear ? > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel