Automatically allow OSs to create dedicated memory allocators #138
Conversation
Some memory controllers have the ability to tune the ECC parameters for a given memory region. This can be useful to create memory carveouts with ECC disabled to store data that don't require it like framebuffers, when the rest of the system might benefit from it still. Signed-off-by: Maxime Ripard <[email protected]>
OSs might want to create dedicated, special purposes, memory allocators from memory regions with different memory attributes or characteristics, for the rest of the system to consume. Let's add an export property to allow reserved memory regions to be used as the backing memory for such allocators. Signed-off-by: Maxime Ripard <[email protected]>
| which can be corrected by the Error-Correction Code (ECC) memory | ||
| subsystem (typically 0, 1 or 2). | ||
|
|
||
| export: |
There was a problem hiding this comment.
Shouldn't this be mutually exclusive with no-map and reusable?
There was a problem hiding this comment.
That's one of the things I wasn't too sure about. I don't think it's mutually exclusive with no-map per se. If we take the Linux example, we can totally create dma-buf from memory that isn't accessible to the CPU.
reusable however looks like it could be made mutually exclusive with it.
Hi, 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-xtFDHHqqyrroCMQ@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. I submitted a draft PR to the DT schema for the bindings used in this PR: devicetree-org/dt-schema#138 Let me know what you think, Maxime To: Rob Herring <[email protected]> To: Saravana Kannan <[email protected]> To: Sumit Semwal <[email protected]> To: Benjamin Gaignard <[email protected]> To: Brian Starkey <[email protected]> To: John Stultz <[email protected]> To: T.J. Mercier <[email protected]> To: Christian König <[email protected]> Cc: Mattijs Korpershoek <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Signed-off-by: Maxime Ripard <[email protected]> --- Changes in v2: - EDITME: describe what is new in this series revision. - EDITME: use bulletpoints and terse descriptions. - Link to v1: https://lore.kernel.org/r/[email protected] --- b4-submit-tracking --- # This section is used internally by b4 prep for tracking purposes. { "series": { "revision": 2, "change-id": "20240515-dma-buf-ecc-heap-28a311d2c94e", "prefixes": [], "history": { "v1": [ "[email protected]" ] } } }
|
The existing properties we have and the combinations of them already makes handling reserved-memory a challenge. I don't think we need more generic stuff and more combinations. If you need a region allocated to something in particular, then add a compatible for it. For ECC, that seems like OS policy on what to do with errors. AFAIK, there's not per region ECC support in any h/w. The Linux kernel can do per region handling already. For example, if an ECC error is in a user process memory, then it can just kill the process. If you want to ignore errors in framebuffers, then the framebuffer driver should register that memory and handle the errors itself. |
So you would prefer to have something like an 'exported-region' compatible?
It's not so much about ignoring the errors, it's about disabling it outright. Some platforms have the ECC data in-band so you're wasting memory for something useless in that context. And there's a performance penalty too. Ignoring the ECC errors will still have the memory usage and performance penalties. |
Here's a draft series to add the ability for the OS to create dedicated memory allocators from carved-out memory regions with memory attributes or parameters different from the rest of the system.
This is useful, for example, on systems with ECC enabled to create dedicated memory regions where ECC is disabled so the system is protected by default, but we can still opt-out of that protection for usage specific buffers. For example, framebuffers are usually fairly big, and a bitflip would marginally affect the color of a pixel. This doesn't justify the downsides of enabling ECC on some platforms (increased memory usage, lower performance).
Thanks for looking into it!