[openib-general] Re: Re: [Andrew Morton] inappropriate use of in_atomic()

[Libor Michalek]

On Mon, Mar 28, 2005 at 08:05:10PM -0800, Grant Grundler wrote:
> On Mon, Mar 28, 2005 at 05:55:23PM -0800, Libor Michalek wrote:
> > On Sun, Mar 27, 2005 at 05:58:47PM +0200, Michael S. Tsirkin wrote:
> > > 
> > > My understanding is you must give kmap_atomic the proper parameter:
> > > KM_IRQ0/KM_SOFTIRQ0/KM_USR0, to avoid conflicts with other callers of
> > > kmap on the same CPU.
> > > 
> > > Something like this then?
> > 
> >   If you're going to check for in_irq() why not just use kmap() when
> > you are not in an interrupt? I think the benefit of using kmap_atomic
> > all the time is that you don't need to check if you are in an
> > interrupt, you just need to make sure the local interrupts are
> > disabled in case you are not in an interrupt.
> 
> Sorry - parsing that last sentence kept me busy for a bit. :^)
> 
> I just wanted to point out that checking if the CPU is in an interrupt
> context can be more expensive than blindly turning interrupts off.
> If the branch is mispredicted, one looses on most architectures.
> Typically, masking *all* interrupts for the "current" cpu is a very
> efficient operation and has a smaller i-cache footprint.

  Sorry for the obfuscation. What I wanted to say, if we're going to
use kmap_atomic all the time, don't bother checking if we are in an
interrupt, instead always disable interrupt before calling kmap_atomic
and always use the same km_type. There will not be a collision on the
km_type if interrupts are disabled, so there's no reason to use
different km_types in different states. At least that's my understanding
of how kmap_atomic works.

-Libor