On Monday 20 September 2010 19:50:59 Nicolas Pitre wrote:
I believe that this is related to LPAE -- the usual 32-bit-only DMA devices in a >32-bit physical address space. But there was also discussion about run-time patching for SMP alternatives, though I am missing how this relates to highmem. Enlightenment?
Wrt SD/MMC performance, if we're talking about device access, then all the DMA-using hardware configs I've seen are only limited by the media speed which is typically much slower than a hard disk, or even a SSD for that matter (and so is the price).
Right. Having an intelligent file system is the only way I can see for getting good speedups, by avoiding erase-cycles inside the SD card, which commonly happen when you write to sectors at random addresses.
There has been a lot of research in optimizing for regular NAND flash, at least some of which should apply to SD cards as well, although their naive wear-levelling algorithms might easily get in the way.
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.
Arnd