[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20201124101656.GA9682@infradead.org>
Date: Tue, 24 Nov 2020 10:16:56 +0000
From: Christoph Hellwig <hch@...radead.org>
To: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
Cc: "luto@...nel.org" <luto@...nel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"daniel@...earbox.net" <daniel@...earbox.net>,
"peterz@...radead.org" <peterz@...radead.org>,
"jeyu@...nel.org" <jeyu@...nel.org>,
"bpf@...r.kernel.org" <bpf@...r.kernel.org>,
"rppt@...nel.org" <rppt@...nel.org>,
"ast@...nel.org" <ast@...nel.org>,
"linux-mm@...ck.org" <linux-mm@...ck.org>,
"dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
"Weiny, Ira" <ira.weiny@...el.com>,
"x86@...nel.org" <x86@...nel.org>,
"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
"Reshetova, Elena" <elena.reshetova@...el.com>,
"Williams, Dan J" <dan.j.williams@...el.com>
Subject: Re: [PATCH RFC 01/10] vmalloc: Add basic perm alloc implementation
On Mon, Nov 23, 2020 at 12:01:35AM +0000, Edgecombe, Rick P wrote:
> Another option could be putting the new metadata in vm_struct and just
> return that, like get_vm_area(). Then we don't need to invent a new
> struct. But then normal vmalloc()'s would have a bit of wasted memory
> since they don't need this metadata.
That would seem most natural to me. We'll need to figure out how we
can do that without bloating vm_struct too much. One option would
be a bigger structure that embedds vm_struct and can be retreived using
container_of().
Powered by blists - more mailing lists