On Wed, May 15, 2024 at 6:57 AM Maxime Ripard <mrip...@kernel.org> wrote: > This series is the follow-up of the discussion that John and I had a few > months ago here: > > https://lore.kernel.org/all/candhncqujn6bh3kxkf65bwitylvqsd9892-xtfdhhqqyrro...@mail.gmail.com/ > > 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 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. > > We could also easily extend this mechanism to support more flags, or > through a new ioctl to discover which flags a given heap supports.
Hey! Thanks for sending this along! I'm eager to see more heap related work being done upstream. The only thing that makes me a bit hesitant, is the introduction of allocation flags (as opposed to a uniquely specified/named "ecc" heap). We did talk about this earlier, and my earlier press that only if the ECC flag was general enough to apply to the majority of heaps then it makes sense as a flag, and your patch here does apply it to all the heaps. So I don't have an objection. But it makes me a little nervous to add a new generic allocation flag for a feature most hardware doesn't support (yet, at least). So it's hard to weigh how common the actual usage will be across all the heaps. I apologize as my worry is mostly born out of seeing vendors really push opaque feature flags in their old ion heaps, so in providing a flags argument, it was mostly intended as an escape hatch for obviously common attributes. So having the first be something that seems reasonable, but isn't actually that common makes me fret some. So again, not an objection, just something for folks to stew on to make sure this is really the right approach. Another thing to discuss, that I didn't see in your mail: Do we have an open-source user of this new flag? thanks -john
