Rough notes from Kernel Consolidation meeting

Arnd Bergmann arnd at
Mon Sep 20 20:58:20 BST 2010

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.


More information about the linaro-dev mailing list