Re: about runqueues locking

[Zwane Mwaikambo]

On Fri, 27 Feb 2004, Vincent Hanquez wrote:

> I've got a code for 2.4 which do:
>
> ================================================================
> spin_lock_irqsave(&runqueue_lock, flags)
> for_each_process(p)
> {
> 	// modify p attributes
> }
> spin_unlock_irqrestore(&runqueue_lock, flags)
> ================================================================
>
> and I need to translate it to 2.6.
> What is exactly the best solution since runqueues are per cpu now ?

runqueue locking is done in ascending order when you want to lock multiple
runqueues, i.e. you have to lock cpu_rq(0) before cpu_rq(1). There are
functions to aid in doing double lock acquisitions, namely
double_rq_lock() which does all the work for you.

> or if not, is tasklist_lock can be use to lock all runqueues at once ?

If you're going to be walking the task list and modifying then you just
need to write_lock the tasklist_lock. Some operations may require you to
lock the task's runqueue, in which case the runqueue lock must be done
within the tasklist_lock.

> and one another question, what is the difference between
> local_irq_disable() and local_irq_save() ?
> irq_save push eflags register on the stack, but why for ?

local_irq_save() is for when you don't know the interrupt enable status
and would like to restore it upon exit of the given per cpu critical
section. local_irq_disable() is normally paired with a local_irq_enable() so it
unconditionally enables interrupts, something you may not always want to
do. If unsure, local_irq_save() is always the safe bet. You may also find
the following of interest;

http://www.kernel.org/pub/linux/kernel/people/rusty/kernel-locking/
-
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/