[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <dbea2e8b-41ea-565c-a78e-61105e23fc08@nvidia.com>
Date: Fri, 12 May 2023 19:06:15 -0700
From: John Hubbard <jhubbard@...dia.com>
To: Ard Biesheuvel <ardb@...nel.org>
CC: Andrew Morton <akpm@...ux-foundation.org>,
Catalin Marinas <catalin.marinas@....com>,
Will Deacon <will@...nel.org>,
Anshuman Khandual <anshuman.khandual@....com>,
Mark Rutland <mark.rutland@....com>,
Kefeng Wang <wangkefeng.wang@...wei.com>,
Feiyang Chen <chenfeiyang@...ngson.cn>,
Alistair Popple <apopple@...dia.com>,
Ralph Campbell <rcampbell@...dia.com>,
<linux-arm-kernel@...ts.infradead.org>,
LKML <linux-kernel@...r.kernel.org>, <linux-mm@...ck.org>,
<stable@...r.kernel.org>
Subject: Re: [PATCH] arm64/mm: don't WARN when alloc/free-ing device private
pages
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
Powered by blists - more mailing lists