From owner-freebsd-arch Fri Sep 20 18:59:30 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9592937B401 for ; Fri, 20 Sep 2002 18:59:29 -0700 (PDT) Received: from 2-225.ctame701-1.telepar.net.br (2-225.ctame701-1.telepar.net.br [200.193.160.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id E37CA43E75 for ; Fri, 20 Sep 2002 18:59:27 -0700 (PDT) (envelope-from riel@conectiva.com.br) Received: from localhost ([IPv6:::ffff:127.0.0.1]:37036 "EHLO localhost") by imladris.surriel.com with ESMTP id ; Fri, 20 Sep 2002 22:59:05 -0300 Date: Fri, 20 Sep 2002 22:59:03 -0300 (BRT) From: Rik van Riel X-X-Sender: riel@imladris.surriel.com To: Terry Lambert Cc: "Bill Huey (Hui)" , Julian Elischer , Subject: Re: New Linux threading model In-Reply-To: <3D8BBFFD.E1CDEAD5@mindspring.com> Message-ID: X-spambait: aardvark@kernelnewbies.org X-spammeplease: aardvark@nl.linux.org MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, 20 Sep 2002, Terry Lambert wrote: > In the design I'm talking about, there are is only a single lock, > and that lock is on a migration queue, into which you *push* > entries. This is different from both the Linux scheduler, and the > current FreeBSD scheduler, and the current FreeBSD scheduler with > Alfred's old (last year) affinity patches applied. Very nice design, IF the cost of contention is higher than the cost of having CPUs sit idle until the next rescheduling happens on one of the busier CPUs... Say that you have a moderately loaded box with, on average, about as many runnable tasks as you have CPUs. These tasks will, due to statistics, not always be evenly distributed across CPUs. Say that distribution is near-perfect and this results in only 1% CPU idle time. Your scheme would win ONLY if the lock contention in the pull model is responsible for more than that 1% CPU time. If we can keep the CPUs busier by pulling tasks onto idle CPUs and the locking overhead is less than 1%, it's a win. regards, Rik -- Bravely reimplemented by the knights who say "NIH". http://www.surriel.com/ http://distro.conectiva.com/ Spamtraps of the month: september@surriel.com trac@trac.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message