Hi...
On 26/05/2011, Jeff Haran <jharan@xxxxxxxxxxxxxx> wrote:
> What I have yet to find in the available documentation is whether in
> this scenario it would be safe to call spin_lock_bh() to acquire the
> lock from code that executes in soft IRQ context.
lxr tells me that eventually spin_lock_bh() will call:
static inline void __raw_spin_lock_bh(raw_spinlock_t *lock)
{
local_bh_disable();
preempt_disable();
spin_acquire(&lock->dep_map, 0, 0, _RET_IP_);
LOCK_CONTENDED(lock, do_raw_spin_trylock, do_raw_spin_lock);
}
seems nothing dangerous if you do it inside soft IRQ, but the question
is "do you absolutely need such locking?"
because , again, lock contention is soft irq IMHO is a big no. You
will likely put all the soft IRQs in queue, thus it might decrease
interactivity, perfomance, throughput and so on. Not to mention, to
some degree, process switching is delayed too.
So unless you could do microbenchmarking and absolutely sure the
effect is negligible, I suggest don't do it.
--
regards,
Mulyadi Santosa
Freelance Linux trainer and consultant
blog: the-hydra.blogspot.com
training: mulyaditraining.blogspot.com
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@xxxxxxxxxxxxxxxxx
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
