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