From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S262764AbUB0NIy (ORCPT ); Fri, 27 Feb 2004 08:08:54 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262843AbUB0NIy (ORCPT ); Fri, 27 Feb 2004 08:08:54 -0500 Received: from dragnfire.mtl.istop.com ([66.11.160.179]:12743 "EHLO dsl.commfireservices.com") by vger.kernel.org with ESMTP id S262764AbUB0NIu (ORCPT ); Fri, 27 Feb 2004 08:08:50 -0500 Date: Fri, 27 Feb 2004 08:08:37 -0500 (EST) From: Zwane Mwaikambo To: Vincent Hanquez Cc: lkml Subject: Re: about runqueues locking In-Reply-To: <20040227122311.GA28181@snarc.org> Message-ID: References: <20040227122311.GA28181@snarc.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org 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/