On Thursday 23 September 2010, Nicolas Pitre wrote:
This highmem topic comes from the fact that highmem will be needed in the period of time between now and LPAE where we have boards with lots of memory but we can't address it all without highmem (unless we want to revisit the 3g/1g split, but I personally think not).
Note that LPAE does require highmem to be useful. The only way highmem could be avoided is to move to a 64-bit architecture.
Right, I'd even say LPAE can only make things worse because people will stick even more memory into their systems, most of which then becomes highmem.
We might be able to use MMU features to implement a 4G/4G split, which lets us use 3GB physical RAM or more (depending on vmalloc and I/O sizes) without highmem, but can have an even higher cost by significantly slowing down uaccess.
Arnd, Nicolas, would either of you take an action to benchmark the cost of CONFIG_HIGHMEM? That would help understanding what kind of work we're looking at
Sure. I don't think the highmem overhead is that significant, especially when it doesn't kick in i.e. when total RAM is below 800MB or so. But I'm skeptical about the gain that runtime patching for this particular case could bring.
Yes, that's what I thought after looking into the thing in more detail. It looked promising at first, but I now doubt it would be measurable.
Arnd