On Thu, Sep 11, 2025 at 12:01 AM Maxime Ripard <mripard@xxxxxxxxxx> wrote: > > Hi TJ, > > On Wed, Sep 10, 2025 at 01:44:45PM -0700, T.J. Mercier wrote: > > On Wed, Sep 10, 2025 at 12:33 AM Maxime Ripard <mripard@xxxxxxxxxx> wrote: > > > > > > On Tue, Aug 26, 2025 at 09:36:03AM +0200, Maxime Ripard wrote: > > > > Hi, > > > > > > > > On Mon, Jul 21, 2025 at 01:17:29PM +0200, Maxime Ripard wrote: > > > > > Here's another attempt at supporting user-space allocations from a > > > > > specific carved-out reserved memory region. > > > > > > > > > > The initial problem we were discussing was that I'm currently working on > > > > > a platform which has a memory layout with ECC enabled. However, enabling > > > > > the ECC has a number of drawbacks on that platform: lower performance, > > > > > increased memory usage, etc. So for things like framebuffers, the > > > > > trade-off isn't great and thus there's a memory region with ECC disabled > > > > > to allocate from for such use cases. > > > > > > > > > > After a suggestion from John, I chose to first start using heap > > > > > allocations flags to allow for userspace to ask for a particular ECC > > > > > setup. This is then backed by a new heap type that runs from reserved > > > > > memory chunks flagged as such, and the existing DT properties to specify > > > > > the ECC properties. > > > > > > > > > > After further discussion, it was considered that flags were not the > > > > > right solution, and relying on the names of the heaps would be enough to > > > > > let userspace know the kind of buffer it deals with. > > > > > > > > > > Thus, even though the uAPI part of it had been dropped in this second > > > > > version, we still needed a driver to create heaps out of carved-out memory > > > > > regions. In addition to the original usecase, a similar driver can be > > > > > found in BSPs from most vendors, so I believe it would be a useful > > > > > addition to the kernel. > > > > > > > > > > Some extra discussion with Rob Herring [1] came to the conclusion that > > > > > some specific compatible for this is not great either, and as such an > > > > > new driver probably isn't called for either. > > > > > > > > > > Some other discussions we had with John [2] also dropped some hints that > > > > > multiple CMA heaps might be a good idea, and some vendors seem to do > > > > > that too. > > > > > > > > > > So here's another attempt that doesn't affect the device tree at all and > > > > > will just create a heap for every CMA reserved memory region. > > > > > > > > > > It also falls nicely into the current plan we have to support cgroups in > > > > > DRM/KMS and v4l2, which is an additional benefit. > > > > > > > > > > Let me know what you think, > > > > > Maxime > > > > > > > > Any chance we can get this merged? > > > > > > Guys, can we move forward on this? > > > > > > Maxime > > > > Hi Maxime, > > > > Sorry I've been MIA the last couple of months. > > > > The docs for the "reusable" property say, "device driver(s) owning the > > region need to be able to reclaim it back", but how can a driver > > reclaim memory backing a dmabuf, since pages allocated for a dmabuf > > aren't necessarily movable. Couldn't a user allocate all of it, and > > refuse to close those dmabufs? > > I guess, but how is that any different than what we're doing on the > default allocator already? Yeah fair, it's not. I'm thinking that makes determining a size for a reusable driver-specified region that's always exposed to userspace a bit fuzzy. The requirements for the driver can probably be known, but for potentially unrelated allocations from userspace? The default ownership / file permissions for the heap would have to be changed to allow those non-reclaimable allocations, so maybe that's enough of an opt-in for such regions. > It also has to be reusable, and will not be able to reclaim any memory > allocated through the heap. > > > I backported this to 6.6 and ran it on a Pixel. While there are > > already similar out-of-tree dmabuf heap drivers that expose heaps for > > these reserved regions, they do more than just cma_alloc (multiple > > flavors of buffer securing, use case specific alignment and padding, > > and slightly different allocation strategies) so I don't think this > > series would allow us to completely drop the custom heap code, but > > it's a nice start. > > Thanks for testing, and I totally expect more heaps coming for things > like protected memory, but it should indeed reduce the number of heap > drivers needed going forward. > > > Does the cgroup part come in because the plan is to add charging in > > cma_heap.c? > > Yes, and the system heap as well. > > Maxime Thanks, Reviewed-by: T.J. Mercier <tjmercier@xxxxxxxxxx>
