Re: [patch] x86: optimize __pa() to be linear again on 64-bit x86

[Tejun Heo]

Hello, Ingo.

Ingo Molnar wrote:
> * Tejun Heo <tj@xxxxxxxxxx> wrote:
> 
>> Hello,
>>
>> Ingo Molnar wrote:
>>> Yeah, we can do this complete conversion.
>>>
>>> I'll clean it up some more. I think the best representation of 
>>> this will be via a virt_to_sym() and sym_to_virt() space. That 
>>> makes it really clear when we are moving from the symbol space 
>>> to the linear space and back.
>> For arch code, maybe it's maintainable but with my driver developer
>> hat on I gotta say virt_to_page() not working on .data/.bss is quite
>> scary. [...]
> 
> Well, we have a debug mechanism in place.
> 
> As i suggested it in my first mail we can run with debug enabled 
> for a cycle and then turn on the optimization by default (with 
> the debug option still available too).

I don't know.  The failure mode just seems to subtle to me and we'll
be able to gain most of the benefits by using the fast version at
appropriate places without adding any risk.

> Drivers doing DMA on .data/.bss items is rather questionable 
> anyway (and dangerous as well, on any platform where there's 
> coherency problems if DMA is misaligned, etc.), and a quick look 
> shows there's at most 2-3 dozen examples of that in all of 
> drivers/*.

Gained benefit vs. added danger equation just doesn't seem right to
me.  Yes, we'll be able to filter most of them in a cycle or two but
we will never know whether it's fully safe or not.  Please note that
when it goes wrong, it can go wrong silently corrupting some unrelated
stuff.  When there is a way to achieve almost the same level of
performance gain in safe way, I don't think doing it this way is a
good choice.  Also, if we do this, we're basically introducing new API
by changing semantics of an existing one in a way that can break the
current users, which we really should avoid.

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/