From owner-freebsd-performance@FreeBSD.ORG Wed Oct 24 18:19:28 2007 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EA7C516A417 for ; Wed, 24 Oct 2007 18:19:28 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from webaccess-cl.virtdom.com (webaccess-cl.virtdom.com [216.240.101.25]) by mx1.freebsd.org (Postfix) with ESMTP id AACEC13C4B3 for ; Wed, 24 Oct 2007 18:19:28 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from [192.168.1.104] (cpe-66-91-190-165.hawaii.res.rr.com [66.91.190.165]) (authenticated bits=0) by webaccess-cl.virtdom.com (8.13.6/8.13.6) with ESMTP id l9OIJCrK062023 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Wed, 24 Oct 2007 14:19:14 -0400 (EDT) (envelope-from jroberson@chesapeake.net) Date: Wed, 24 Oct 2007 11:21:30 -0700 (PDT) From: Jeff Roberson X-X-Sender: jroberson@10.0.0.1 To: Josh Carroll In-Reply-To: <8cb6106e0710230902x4edf2c8eu2d912d5de1f5d4a2@mail.gmail.com> Message-ID: <20071024111105.M598@10.0.0.1> References: <8cb6106e0710230902x4edf2c8eu2d912d5de1f5d4a2@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: remy.nonnenmacher@activnetworks.com, freebsd-performance@freebsd.org Subject: Re: ULE vs. 4BSD in RELENG_7 X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2007 18:19:29 -0000 On Tue, 23 Oct 2007, Josh Carroll wrote: > Hello, > > I posted this to the stable mailing list, as I thought it was > pertinent there, but I think it will get better attention here. So I > apologize in advance for cross-posting if this is a faux pas. :) > > Anyway, in summary, ULE is about 5-6 % slower than 4BSD for two > workloads that I am sensitive to: building world with -j X, and ffmpeg > -threads X. Other benchmarks seem to indicate relatively equal > performance between the two. MySQL, on the other hand, is > significantly faster in ULE. > > I'm trying to understand why ffmpeg and buildworld are slower in ULE > than 4BSD, since it seems to me that ULE was supposed to be the better > scaling scheduler. > > Here is a link to the original thread on the stable mailing list: > > http://lists.freebsd.org/pipermail/freebsd-stable/2007-October/037379.html > > Remy replied with some interesting results for building world between > the two schedulers on an 8-way system. It seems that ULE suffers as > more threads/processes are thrown at it, at least it appears that way > from Remy's data. > > Does anyone have any additional performance tests I can run that might > help indicate where the deficiency is in the ULE scheduler? MySQL > performance is excellent, so I'm wondering if it was tuned to that > particular workload? > > I'm not sure if Remy subscribes to this list, so I am CC'ing him. Hope > you don't mind Remy :) Josh, Thanks for your emails. First, as gnn mentioned, I'm without most of my things at the moment. I have some patches which might improve your workload but I need to test and tune them more myself before I give them out. I doubt any of the sysctls other than steal_thresh and balance_ticks will help your situation. ULE is tuned for workloads that benefit from improved affinity. Not necessarily mysql in particular. Tests with other workloads that benefit from improved affinity have verified that it's not really mysql specific tuning. The problem with buildworld for ULE is that 4BSD gets basically perfect affinity and perfect balancing because the compiler runs, typically uninterrupted, until it does a blocking disk transaction. At that point it doesn't matter which CPU it is resumed on. Your tests with ffmpeg threads vs processes probably is triggering more context switches due to lock contention in the kernel in the threads case. This is also likely the problem with some super-smack tests. On each context switch 4BSD has an opportunity to perfectly balance the CPUs. ULE does not because it's too costly and hinders other workloads. I don't doubt that we can improve things further. It will just have to wait for another few weeks before I'm able to do much about it. Thanks, Jeff > > Regards, > Josh > _______________________________________________ > freebsd-performance@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-performance > To unsubscribe, send any mail to "freebsd-performance-unsubscribe@freebsd.org" >