Hi Marc,
I've been re-reviewing the code and I can't see any problem. There
are two cases: kernels compiled with CONFIG_HIGHMEM and those
without.
For the CONFIG_HIGHMEM case, the call in bh_kmap_irq to kmap_atomic
actually calls a real routine called kmap_atomic. This has a version
of the 'if' statement equivalent to the one I removed from
bh_kmap_irq, right near the front:
static inline void *kmap_atomic(...
{
....
preempt_disable();
if (page < highmem_start_page)
return page_address(page);
For the case where CONFIG_HIGHMEM is not set, the bh_kmap_irq call to
kmap_atomic is really (through the magic of #defines) a call to
page_address, which expands out to a near-NOP:
#define page_address(page) ((page)->virtual)
So in one case I have the overhead of an extra procedure call/return,
in the other the overhead of an extra pointer dereference. Neither
of these should be causing the performance impact you are seeing.
There is always the possibility of a case that I missed, but right
now I don't see it.
Regards,
Joe
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/