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 _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
