On Mon, Sep 20, 2010, Arnd Bergmann wrote:
> > Wrt highmem: I can't see the link with highmem and SMP. As far as I
> > know, highmem on ARM should be SMP safe already (the only SMP related
> > issue I've seen has been fixed in commit 831e8047eb).
>
> Right, it's not related to SMP, I was thinking of using run-time
> patching for for both highmem and SMP though. My idea was to use
> make the decision between simply doing page_address() and the full
> kmap()/kmap_atomic() statically at boot time depending on the
> amount of memory.
>
> I looked at the functions again, and I'm now guessing that the difference
> would be minimal because the first thing we check is (PageHighMem(page))
> on a presumably cache-hot struct page. It may be worthwhile comparing
> the performance of a highmem-enabled kernel with a regular kernel
> on a system without highmem, but it may very well be identical.
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).
I proposed making highmem the default across all Linaro kernels as a
way to simplify things, perhaps removing the need to bother about this
config option altogether.
This proposal does need some investigation on runtime performance; if
highmem is basically free, then we're good and we can just enable it by
default. If it's not, I proposed we do runtime patching just like SMP
(exactly what Arnd proposed).
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
Thanks!!
--
Loïc Minier
_______________________________________________
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
