From: Claudio Imbrenda <imbrenda@linux.ibm.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
linux-s390@vger.kernel.org, frankja@linux.ibm.com,
borntraeger@de.ibm.com, cohuck@redhat.com, david@redhat.com,
linux-mm@kvack.org, Nicholas Piggin <npiggin@gmail.com>,
Uladzislau Rezki <urezki@gmail.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>,
David Rientjes <rientjes@google.com>,
Christoph Hellwig <hch@infradead.org>
Subject: Re: [PATCH v3 1/2] mm/vmalloc: add vmalloc_no_huge
Date: Fri, 11 Jun 2021 10:23:30 +0200 [thread overview]
Message-ID: <20210611102330.17701bad@ibm-vm> (raw)
In-Reply-To: <20210610140909.781959d063608710e24e70c9@linux-foundation.org>
On Thu, 10 Jun 2021 14:09:09 -0700
Andrew Morton <akpm@linux-foundation.org> wrote:
> On Thu, 10 Jun 2021 17:42:19 +0200 Claudio Imbrenda
> <imbrenda@linux.ibm.com> wrote:
>
> > The recent patches to add support for hugepage vmalloc mappings
I will put the proper commit ID here
> > added a flag for __vmalloc_node_range to allow to request small
and the name of the flag here
> > pages. This flag is not accessible when calling vmalloc, the only
and improve the wording in general ("order-0 pages" instead of "small
pages")
> > option is to call directly __vmalloc_node_range, which is not
> > exported.
>
> I can find no patch which adds such a flag to __vmalloc_node_range().
> I assume you're referring to "mm/vmalloc: switch to bulk allocator in
> __vmalloc_area_node()"?
>
> Please be quite specific when identifying patches. More specific than
> "the recent patches"!
sorry!
I was referring to this one:
121e6f3258fe393e22c36f61a ("mm/vmalloc: hugepage vmalloc mappings")
which introduces the flag VM_NO_HUGE_VMAP
I will reword the commit to be more specific
> Also, it appears from the discussion at
> https://lkml.kernel.org/r/YKUWKFyLdqTYliwu@infradead.org that we'll be
> seeing a new version of "mm/vmalloc: switch to bulk allocator in
> __vmalloc_area_node()". Would it be better to build these s390 fixes
> into the next version of that patch series rather than as a separate
> followup thing?
>
next prev parent reply other threads:[~2021-06-11 8:24 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-10 15:42 [PATCH v3 0/2] mm: add vmalloc_no_huge and use it Claudio Imbrenda
2021-06-10 15:42 ` [PATCH v3 1/2] mm/vmalloc: add vmalloc_no_huge Claudio Imbrenda
2021-06-10 19:31 ` Uladzislau Rezki
2021-06-10 21:09 ` Andrew Morton
2021-06-11 8:23 ` Claudio Imbrenda [this message]
2021-06-14 2:01 ` Nicholas Piggin
2021-06-10 15:42 ` [PATCH v3 2/2] KVM: s390: fix for hugepage vmalloc Claudio Imbrenda
2021-06-10 15:56 ` Christian Borntraeger
2021-06-10 16:49 ` Claudio Imbrenda
2021-06-10 16:52 ` Christian Borntraeger
2021-06-14 1:43 ` Nicholas Piggin
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=20210611102330.17701bad@ibm-vm \
--to=imbrenda@linux.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=borntraeger@de.ibm.com \
--cc=catalin.marinas@arm.com \
--cc=cohuck@redhat.com \
--cc=david@redhat.com \
--cc=frankja@linux.ibm.com \
--cc=hch@infradead.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-s390@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=npiggin@gmail.com \
--cc=rientjes@google.com \
--cc=tglx@linutronix.de \
--cc=urezki@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.