Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 16 Jul 2001 11:49:00 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 16 Jul 2001 11:48:50 -0400 Received: from e21.nc.us.ibm.com ([32.97.136.227]:1994 "EHLO e21.nc.us.ibm.com") by vger.kernel.org with ESMTP id ; Mon, 16 Jul 2001 11:48:32 -0400 Date: Mon, 16 Jul 2001 08:46:11 -0700 From: Mike Kravetz To: Andi Kleen Cc: Mike Kravetz , David Lang , Larry McVoy , Davide Libenzi , lse-tech@lists.sourceforge.net, linux-kernel@vger.kernel.org Subject: Re: [Lse-tech] Re: CPU affinity & IPI latency Message-ID: <20010716084611.A1186@w-mikek2.des.beaverton.ibm.com> In-Reply-To: <20010713100521.D1137@w-mikek2.des.beaverton.ibm.com> <20010713154305.G1137@w-mikek2.des.beaverton.ibm.com> <20010715221542.B14480@gruyere.muc.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010715221542.B14480@gruyere.muc.suse.de>; from ak@suse.de on Sun, Jul 15, 2001 at 10:15:42PM +0200 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Jul 15, 2001 at 10:15:42PM +0200, Andi Kleen wrote: > On Fri, Jul 13, 2001 at 03:43:05PM -0700, Mike Kravetz wrote: > > - Define a new field in the task structure 'saved_cpus_allowed'. > > With a little collapsing of existing fields, there is room to put > > this on the same cache line as 'cpus_allowed'. > > - In reschedule_idle() if we determine that the best CPU for a task > > is the CPU it is associated with (p->processor), then temporarily > > bind the task to that CPU. The task is temporarily bound to the > > CPU by overwriting the 'cpus_allowed' field such that the task can > > only be scheduled on the target CPU. Of course, the original > > value of 'cpus_allowed' is saved in 'saved_cpus_allowed'. > > - In schedule(), the loop which examines all tasks on the runqueue > > will restore the value of 'cpus_allowed'. > > This sounds racy, at least with your simple description. Even other CPUs > could walk their run queue while the IPI is being processed and reset the > cpus_allowed flag too early. I guess it would need a check in the > schedule loop that restores cpus_allowed that the current CPU is the only > on set in that task's cpus_allowed. You are correct. It is trivial to allow only the 'target' CPU to reset the cpus_allowed field. This was my first thought. However, as you state below we would get into trouble if there was an extremely long delay in that CPU running schedule. The timestamp sounds reasonable, but I was trying to keep it as simple as possible. > This unfortunately would hang the > process if the CPU for some reason cannot process schedules timely, so > it may be needed to add a timestamp also to the task_struct that allows > the restoration of cpus_allowed even from non target CPUs after some > time. -- Mike Kravetz mkravetz@sequent.com IBM Linux Technology Center - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/