From: Matthew Wilcox <willy@infradead.org>
To: Nicholas Piggin <npiggin@gmail.com>
Cc: linux-arch@vger.kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
Will Deacon <will@kernel.org>,
x86@kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Catalin Marinas <catalin.marinas@arm.com>,
Thomas Gleixner <tglx@linutronix.de>,
linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2 1/4] mm/vmalloc: fix vmalloc_to_page for huge vmap mappings
Date: Mon, 13 Apr 2020 06:34:44 -0700 [thread overview]
Message-ID: <20200413133444.GM21484@bombadil.infradead.org> (raw)
In-Reply-To: <20200413125303.423864-2-npiggin@gmail.com>
On Mon, Apr 13, 2020 at 10:53:00PM +1000, Nicholas Piggin wrote:
> vmalloc_to_page returns NULL for addresses mapped by larger pages[*].
> Whether or not a vmap is huge depends on the architecture details,
> alignments, boot options, etc., which the caller can not be expected
> to know. Therefore HUGE_VMAP is a regression for vmalloc_to_page.
>
> This change teaches vmalloc_to_page about larger pages, and returns
> the struct page that corresponds to the offset within the large page.
> This makes the API agnostic to mapping implementation details.
I'm trying to get us away from returning tail pages from various
functions. How much of a pain would it be to return the head page
instead of the tail page? Obviously the implementation gets simpler,
but can the callers cope? I've been focusing on the page cache, so I
haven't been looking at the vmalloc side of things at all.
WARNING: multiple messages have this Message-ID (diff)
From: Matthew Wilcox <willy@infradead.org>
To: Nicholas Piggin <npiggin@gmail.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
linux-arch@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
linux-arm-kernel@lists.infradead.org,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [PATCH v2 1/4] mm/vmalloc: fix vmalloc_to_page for huge vmap mappings
Date: Mon, 13 Apr 2020 06:34:44 -0700 [thread overview]
Message-ID: <20200413133444.GM21484@bombadil.infradead.org> (raw)
Message-ID: <20200413133444.rCqqfh5QelD9zBJtsDCjl7zA_COh0UlkCJkNrRfsY7c@z> (raw)
In-Reply-To: <20200413125303.423864-2-npiggin@gmail.com>
On Mon, Apr 13, 2020 at 10:53:00PM +1000, Nicholas Piggin wrote:
> vmalloc_to_page returns NULL for addresses mapped by larger pages[*].
> Whether or not a vmap is huge depends on the architecture details,
> alignments, boot options, etc., which the caller can not be expected
> to know. Therefore HUGE_VMAP is a regression for vmalloc_to_page.
>
> This change teaches vmalloc_to_page about larger pages, and returns
> the struct page that corresponds to the offset within the large page.
> This makes the API agnostic to mapping implementation details.
I'm trying to get us away from returning tail pages from various
functions. How much of a pain would it be to return the head page
instead of the tail page? Obviously the implementation gets simpler,
but can the callers cope? I've been focusing on the page cache, so I
haven't been looking at the vmalloc side of things at all.
next prev parent reply other threads:[~2020-04-13 13:34 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-13 12:52 [PATCH v2 0/4] huge vmalloc mappings Nicholas Piggin
2020-04-13 12:52 ` Nicholas Piggin
2020-04-13 12:53 ` [PATCH v2 1/4] mm/vmalloc: fix vmalloc_to_page for huge vmap mappings Nicholas Piggin
2020-04-13 12:53 ` Nicholas Piggin
2020-04-13 13:34 ` Matthew Wilcox [this message]
2020-04-13 13:34 ` Matthew Wilcox
2020-04-14 11:31 ` Nicholas Piggin
2020-04-14 11:31 ` Nicholas Piggin
2020-04-13 12:53 ` [PATCH v2 2/4] mm: Move ioremap page table mapping function to mm/ Nicholas Piggin
2020-04-13 12:53 ` Nicholas Piggin
2020-04-13 12:53 ` [PATCH v2 3/4] mm: HUGE_VMAP arch query functions cleanup Nicholas Piggin
2020-04-13 12:53 ` Nicholas Piggin
2020-04-13 12:53 ` [PATCH v2 4/4] mm/vmalloc: Hugepage vmalloc mappings Nicholas Piggin
2020-04-13 12:53 ` Nicholas Piggin
2020-04-13 13:41 ` Matthew Wilcox
2020-04-13 13:41 ` Matthew Wilcox
2020-04-14 11:39 ` Nicholas Piggin
2020-04-14 11:39 ` Nicholas Piggin
2020-04-14 12:28 ` Christophe Leroy
2020-04-14 12:28 ` Christophe Leroy
2020-04-14 14:20 ` Matthew Wilcox
2020-04-14 14:20 ` Matthew Wilcox
2020-04-14 7:23 ` Christoph Hellwig
2020-04-14 7:23 ` Christoph Hellwig
2020-04-14 12:13 ` Nicholas Piggin
2020-04-14 12:13 ` Nicholas Piggin
2020-04-14 13:02 ` Christoph Hellwig
2020-04-14 13:02 ` Christoph Hellwig
2020-04-14 14:48 ` Nicholas Piggin
2020-04-14 14:48 ` Nicholas Piggin
2020-04-15 10:47 ` Will Deacon
2020-04-15 10:47 ` Will Deacon
2020-04-16 2:38 ` Nicholas Piggin
2020-04-16 2:38 ` Nicholas Piggin
2020-07-01 7:10 ` Zefan Li
2020-07-03 0:15 ` Nicholas Piggin
2020-07-20 2:02 ` Zefan Li
2020-07-20 2:02 ` Zefan Li
2020-07-20 2:49 ` Nicholas Piggin
2020-04-14 0:27 ` [PATCH v2 0/4] huge " David Rientjes
2020-04-14 12:23 ` Nicholas Piggin
2020-04-14 12:23 ` 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=20200413133444.GM21484@bombadil.infradead.org \
--to=willy@infradead.org \
--cc=bp@alien8.de \
--cc=catalin.marinas@arm.com \
--cc=hpa@zytor.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mingo@redhat.com \
--cc=npiggin@gmail.com \
--cc=tglx@linutronix.de \
--cc=will@kernel.org \
--cc=x86@kernel.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).