From: Christoph Hellwig <hch@infradead.org>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: bpf@vger.kernel.org, daniel@iogearbox.net, andrii@kernel.org,
torvalds@linux-foundation.org, brho@google.com,
hannes@cmpxchg.org, lstoakes@gmail.com,
akpm@linux-foundation.org, urezki@gmail.com, hch@infradead.org,
linux-mm@kvack.org, kernel-team@fb.com
Subject: Re: [PATCH bpf-next] mm: Introduce vm_area_[un]map_pages().
Date: Tue, 20 Feb 2024 21:52:14 -0800 [thread overview]
Message-ID: <ZdWPjmwi8D0n01HP@infradead.org> (raw)
In-Reply-To: <20240220192613.8840-1-alexei.starovoitov@gmail.com>
On Tue, Feb 20, 2024 at 11:26:13AM -0800, Alexei Starovoitov wrote:
> From: Alexei Starovoitov <ast@kernel.org>
>
> vmap() API is used to map a set of pages into contiguous kernel virtual space.
>
> BPF would like to extend the vmap API to implement a lazily-populated
> contiguous kernel virtual space which size and start address is fixed early.
>
> The vmap API has functions to request and release areas of kernel address space:
> get_vm_area() and free_vm_area().
As said before I really hate growing more get_vm_area and
free_vm_area outside the core vmalloc code. We have a few of those
mostly due to ioremap (which is beeing consolidate) and executable code
allocation (which there have been various attempts at consolidation,
and hopefully one finally succeeds..). So let's take a step back and
think how we can do that without it.
For the dynamically growing part do you need a special allocator or
can we just go straight to the page allocator and implement this
in common code?
> For BPF use case the area_size will be 4Gbyte plus 64Kbyte of guard pages and
> area->addr known and fixed at the program verification time.
How is this ever going to to work on 32-bit platforms?
next prev parent reply other threads:[~2024-02-21 5:52 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-20 19:26 [PATCH bpf-next] mm: Introduce vm_area_[un]map_pages() Alexei Starovoitov
2024-02-21 5:52 ` Christoph Hellwig [this message]
2024-02-21 19:05 ` Alexei Starovoitov
2024-02-22 23:25 ` Alexei Starovoitov
2024-02-24 0:00 ` Alexei Starovoitov
2024-02-23 17:14 ` Christoph Hellwig
2024-02-23 17:27 ` Alexei Starovoitov
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=ZdWPjmwi8D0n01HP@infradead.org \
--to=hch@infradead.org \
--cc=akpm@linux-foundation.org \
--cc=alexei.starovoitov@gmail.com \
--cc=andrii@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=brho@google.com \
--cc=daniel@iogearbox.net \
--cc=hannes@cmpxchg.org \
--cc=kernel-team@fb.com \
--cc=linux-mm@kvack.org \
--cc=lstoakes@gmail.com \
--cc=torvalds@linux-foundation.org \
--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 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).