From: "Christoph Lameter (Ampere)" <cl@linux.com>
To: Matthew Wilcox <willy@infradead.org>
Cc: Shubhang Kaushik OS <Shubhang@os.amperecomputing.com>,
"ampere-linux-kernel@lists.amperecomputing.com"
<ampere-linux-kernel@lists.amperecomputing.com>,
Andrew Morton <akpm@linux-foundation.org>,
Uladzislau Rezki <urezki@gmail.com>,
Christoph Hellwig <hch@infradead.org>,
Lorenzo Stoakes <lstoakes@gmail.com>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2] vmalloc: Modify the alloc_vmap_area() error message for better diagnostics
Date: Mon, 3 Jun 2024 17:16:13 -0700 (PDT) [thread overview]
Message-ID: <3329c844-509b-8769-01b6-a191b60bee35@linux.com> (raw)
In-Reply-To: <Zl5TSbHZJbtM4xIX@casper.infradead.org>
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=<size> 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.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next parent reply other threads:[~2024-06-04 1:31 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <MN2PR01MB5902582BA403FB9FA12816A6F5FF2@MN2PR01MB5902.prod.exchangelabs.com>
[not found] ` <Zl5TSbHZJbtM4xIX@casper.infradead.org>
2024-06-04 0:16 ` Christoph Lameter (Ampere) [this message]
2024-06-04 2:30 ` [PATCH v2] vmalloc: Modify the alloc_vmap_area() error message for better diagnostics Anshuman Khandual
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3329c844-509b-8769-01b6-a191b60bee35@linux.com \
--to=cl@linux.com \
--cc=Shubhang@os.amperecomputing.com \
--cc=akpm@linux-foundation.org \
--cc=ampere-linux-kernel@lists.amperecomputing.com \
--cc=hch@infradead.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-mm@kvack.org \
--cc=lstoakes@gmail.com \
--cc=urezki@gmail.com \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).