From: John Hubbard <jhubbard@nvidia.com>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
Anshuman Khandual <anshuman.khandual@arm.com>,
Mark Rutland <mark.rutland@arm.com>,
Kefeng Wang <wangkefeng.wang@huawei.com>,
Feiyang Chen <chenfeiyang@loongson.cn>,
Alistair Popple <apopple@nvidia.com>,
Ralph Campbell <rcampbell@nvidia.com>,
<linux-arm-kernel@lists.infradead.org>,
LKML <linux-kernel@vger.kernel.org>, <linux-mm@kvack.org>,
<stable@vger.kernel.org>
Subject: Re: [PATCH] arm64/mm: don't WARN when alloc/free-ing device private pages
Date: Fri, 12 May 2023 19:06:15 -0700 [thread overview]
Message-ID: <dbea2e8b-41ea-565c-a78e-61105e23fc08@nvidia.com> (raw)
In-Reply-To: <CAMj1kXFZ=4hLL1w6iCV5O5uVoVLHAJbc0rr40j24ObenAjXe9w@mail.gmail.com>
On 5/12/23 07:42, Ard Biesheuvel wrote:
>> I'm still not sure of how to make room, but working on it.
>>
>
> The assumption that only the linear map needs to be covered by struct
> pages is rather fundamental to the arm64 mm code, as far as I am
> aware.
>
> Given that these device memory regions have no direct correspondence
> with the linear map at all, couldn't we simply vmalloc() a range of
> memory for struct pages for such a region and wire that up in the
> existing code? That seems far more maintainable to me than
> reorganizing the entire kernel VA space, and only for some choices for
> the dimensions.
The vmalloc approach does sound like it should Just Work, yes. I'll try it out.
And now I'm trying to remember why Jerome didn't use that approach for x86
originally. If this fixes HMM on arm64, I'll revisit that question too.
Really appreciate the help and advice here.
thanks,
--
John Hubbard
NVIDIA
next prev parent reply other threads:[~2023-05-13 2:06 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-06 4:05 John Hubbard
2023-04-06 7:31 ` Ard Biesheuvel
2023-04-07 0:13 ` John Hubbard
2023-04-07 10:45 ` Ard Biesheuvel
2023-04-10 7:39 ` John Hubbard
2023-04-11 2:48 ` John Hubbard
2023-05-12 14:42 ` Ard Biesheuvel
2023-05-13 2:06 ` John Hubbard [this message]
2023-04-06 20:07 ` Andrew Morton
2023-04-06 20:18 ` John Hubbard
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=dbea2e8b-41ea-565c-a78e-61105e23fc08@nvidia.com \
--to=jhubbard@nvidia.com \
--cc=akpm@linux-foundation.org \
--cc=anshuman.khandual@arm.com \
--cc=apopple@nvidia.com \
--cc=ardb@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=chenfeiyang@loongson.cn \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mark.rutland@arm.com \
--cc=rcampbell@nvidia.com \
--cc=stable@vger.kernel.org \
--cc=wangkefeng.wang@huawei.com \
--cc=will@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