From owner-freebsd-performance@FreeBSD.ORG Wed Oct 24 20:33:27 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 905E516A419 for ; Wed, 24 Oct 2007 20:33:27 +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 3B74713C491 for ; Wed, 24 Oct 2007 20:33:27 +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 l9OKX8EM008989 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Wed, 24 Oct 2007 16:33:10 -0400 (EDT) (envelope-from jroberson@chesapeake.net) Date: Wed, 24 Oct 2007 13:35:26 -0700 (PDT) From: Jeff Roberson X-X-Sender: jroberson@10.0.0.1 To: Josh Carroll In-Reply-To: <8cb6106e0710241229i12852d8cq436f4c955ac62c56@mail.gmail.com> Message-ID: <20071024133240.X598@10.0.0.1> References: <8cb6106e0710230902x4edf2c8eu2d912d5de1f5d4a2@mail.gmail.com> <20071024111105.M598@10.0.0.1> <8cb6106e0710241229i12852d8cq436f4c955ac62c56@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 20:33:27 -0000 On Wed, 24 Oct 2007, Josh Carroll wrote: >> 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. > > Thanks for the response Jeff, I appreciate it. Is this something that > the scheduler can recognize and auto-tune itself for? E.g. have it > recognize the scenario differences and do what 4BSD is doing for cases > such as ffmpeg and what ULE otherwise does in other circumstances? I > guess this would not come without its own overhead, which might defeat > the purpose anyway. The problem is the two models are drastically incompatible. Rather than use a shared queue for some threads I'm just going to have to continue to refine the load balancing algorithm. The higher idle time with ULE is a symptom of assinging work to the wrong place. I think I have a good idea of how to improve that cpu selection. > >> 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 again, I do appreciate your work and help. So you're > anticipating nothing can be done at all, or did you mean at the moment > until you get your equipment back and get settled? Or is this > something that would need to be looked at in -current rather than > 7-STABLE? I'm confident that we can improve things. It will probably not make the cut for 7.0 since it will be too disruptive. I'm sure it can be backported before 7.1 when ULE is likely to become the default. I hope that we can continue to work together to verify any fixes I may come up with. 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" >