On Thu, 23 Sep 2010, Loïc Minier wrote:
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).
Note that LPAE does require highmem to be useful. The only way highmem could be avoided is to move to a 64-bit architecture.
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
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.
The runtime patching of the kernel is useful for simple and straight-forward cases such as SMP ops which are performed in assembly. But in this case I'm afraid this could add even more overhead in the end, especially when highmem is active. But if the overhead of simply enabling highmem is not significant enough to be measurable in the first place then this is moot.
Nicolas