ECC memory semantics for heaps

[Maxime Ripard <mripard@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 1390 bytes --]

Hi,

I'm currently working on a platform that seems to have togglable RAM ECC
support. Enabling ECC reduces the memory capacity and memory bandwidth,
so while it's a good idea to protect most of the system, it's not worth
it for things like framebuffers that won't really be affected by a
bitflip.

It's currently setup by enabling ECC on the entire memory, and then
having a region of memory where ECC is disabled and where we're supposed
to allocate from for allocations that don't need it.

My first thought to support this was to create a reserved memory region
for the !ECC memory, and to create a heap to allocate buffers from that
region. That would leave the system protected by ECC, while enabling
userspace to be nicer to the system by allocating buffers from the !ECC
region if it doesn't need it.

However, this creates basically a new combination compared to the one we
already have (ie, physically contiguous vs virtually contiguous), and we
probably would want to throw in cacheable vs non-cacheable too.

If we had to provide new heaps for each variation, we would have 8 heaps
(and 6 new ones), which could be fine I guess but would still increase
quite a lot the number of heaps we have so far.

Is it something that would be a problem? If it is, do you see another
way to support those kind of allocations (like providing hints through
the ioctl maybe?)?

Thanks!
Maxime

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]