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/