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
_______________________________________________
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
