From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Thu, 10 Jan 2002 01:01:50 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Thu, 10 Jan 2002 01:01:42 -0500 Received: from x35.xmailserver.org ([208.129.208.51]:25862 "EHLO x35.xmailserver.org") by vger.kernel.org with ESMTP id ; Thu, 10 Jan 2002 01:01:26 -0500 Date: Wed, 9 Jan 2002 22:06:44 -0800 (PST) From: Davide Libenzi X-X-Sender: davide@blue1.dev.mcafeelabs.com To: Rusty Russell cc: Ingo Molnar , lkml Subject: Re: [PATCH] minor sched-E1 tweaks and questions In-Reply-To: Message-ID: 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 Thu, 10 Jan 2002, Rusty Russell wrote: > Another question: > > if (likely(prev != next)) { > rq->nr_switches++; > rq->curr = next; > next->cpu = prev->cpu; > context_switch(prev, next); > /* > * The runqueue pointer might be from another CPU > * if the new task was last running on a different > * CPU - thus re-load it. > */ > barrier(); > rq = this_rq(); > } > spin_unlock_irq(&rq->lock); > > I do not understand this comment. How can rq (ie. smp_processor_id()) > change? Nothing sleeps here, and if it DID change, the > spin_unlock_irq() would be wrong... If you switch you'll on the stack the rq of the previous cpu spin_unlock_irq(&rq->lock) is fine if you do not switch and if you switch you need to reload rq - Davide