Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sat, 11 Jan 2003 09:38:06 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sat, 11 Jan 2003 09:38:06 -0500 Received: from tmr-02.dsl.thebiz.net ([216.238.38.204]:33548 "EHLO gatekeeper.tmr.com") by vger.kernel.org with ESMTP id ; Sat, 11 Jan 2003 09:36:51 -0500 Date: Sat, 11 Jan 2003 09:43:13 -0500 (EST) From: Bill Davidsen To: Erich Focht cc: linux-kernel , lse-tech Subject: Re: [Lse-tech] Minature NUMA scheduler In-Reply-To: <200301101734.56182.efocht@ess.nec.de> 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 Content-Length: 1275 Lines: 28 On Fri, 10 Jan 2003, Erich Focht wrote: > Having some sort of automatic node affinity of processes and equal > node loads in mind (as design targets), we could: > - take the minimal NUMA scheduler > - if the normal (node-restricted) find_busiest_queue() fails and > certain conditions are fulfilled (tried to balance inside own node > for a while and didn't succeed, own CPU idle, etc... ???) rebalance > over node boundaries (eg. using my load balancer) > This actually resembles the original design of the node affine > scheduler, having the cross-node balancing separate is ok and might > make the ideas clearer. Agreed, but honestly just this explanation would make it easier to understand! I'm not sure you have the "balance of nodes" trigger defined quite right, but I'm assuming if this gets implemented as described that some long term umbalance detector mechanism will be run occasionally. -- bill davidsen CTO, TMR Associates, Inc Doing interesting things with little computers since 1979. - 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/