From owner-freebsd-stable@FreeBSD.ORG Fri Dec 23 23:24:44 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 18D92106564A; Fri, 23 Dec 2011 23:24:44 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) by mx1.freebsd.org (Postfix) with ESMTP id C65068FC19; Fri, 23 Dec 2011 23:24:43 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.5/8.14.5) with ESMTP id pBNNOhW6064529; Fri, 23 Dec 2011 15:24:43 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.5/8.14.5/Submit) id pBNNOhrB064528; Fri, 23 Dec 2011 15:24:43 -0800 (PST) (envelope-from sgk) Date: Fri, 23 Dec 2011 15:24:43 -0800 From: Steve Kargl To: Adrian Chadd Message-ID: <20111223232443.GA64459@troutmask.apl.washington.edu> References: <20111215215554.GA87606@troutmask.apl.washington.edu> <20111222005250.GA23115@troutmask.apl.washington.edu> <20111222103145.GA42457@onelab2.iet.unipi.it> <20111222184531.GA36084@troutmask.apl.washington.edu> <4EF37E7B.4020505@FreeBSD.org> <20111222194740.GA36796@troutmask.apl.washington.edu> <20111223191146.GA56232@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@freebsd.org, Andriy Gapon Subject: Re: SCHED_ULE should not be the default X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2011 23:24:44 -0000 On Fri, Dec 23, 2011 at 02:49:51PM -0800, Adrian Chadd wrote: > On 23 December 2011 11:11, Steve Kargl wrote: > > > One difference between the 2008 tests and today tests is > > the number of available cpus. ?In 2008, I ran the tests > > on a node with 8 cpus, while today's test used only a > > node with only 4 cpus. ?If this behavior is a scaling > > issue, I can't currently test it. ?But, today's tests > > are certainly encouraging. > > Do you not have access to anything with 8 CPUs in it? It'd be nice to > get clarification that this indeed was fixed. I have a few nodes with 8 cpus, but those are running 4BSD kernels. I try to keep my kernel and world sync, and by extension the kernel/world on each node is in sync with all other nodes. So, while I took the 4 cpu node off-line and updated it, at the moment I can't take another node off-line unless I do an update across the entire cluster. The update is planned for next year. > Does ULE care (much) if the nodes are hyperthreading or real cores? > Would that play a part in what it tries to schedule/spread? I only have opteron processors in the cluster, if you're referring to Intel's hypertheading technology, I can't look into ULE's behavior with HTT. -- Steve