From owner-freebsd-performance@FreeBSD.ORG Sat Nov 20 01:49:58 2010 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 0CFD61065670; Sat, 20 Nov 2010 01:49:58 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 45DA08FC18; Sat, 20 Nov 2010 01:49:56 +0000 (UTC) Received: by wyb35 with SMTP id 35so4331934wyb.13 for ; Fri, 19 Nov 2010 17:49:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=wZO0ulBRbTTkGcgy2Q32ThZN1QGyz5faGrbY6qdrhk4=; b=uMvThrM186fUIob7w7ojR5UPi6e+LsRZBxYjxmecGe53nMLZV7NcvbmWSIbIn6/Q36 tDFf7pr/s2OZPFI+ReQ8Jej7NPYOA8mItz7EwRqGIjRRCcYaBifN4IetxHTWhiczPM9k kKuDEdoFgnFI/TvI9p+77w5/mkP3PcF+xq3nI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=QvOVQpuXF+ey5BdpdazZZWZEN5lEbfh7yHaXmQlED6WoTcrqpiYuW78hwoRMr2pThB TP9mMEO2wNMQzeiuUda4qpQPt/gulAT6pVzM/nyyNnwniq5k16Qh4aihLshY8EpR73/T EZvzUMGrY2qjvc90vH3hg3sRXrb27frZ5xJC4= MIME-Version: 1.0 Received: by 10.216.7.210 with SMTP id 60mr1774698wep.30.1290217795101; Fri, 19 Nov 2010 17:49:55 -0800 (PST) Sender: yanegomi@gmail.com Received: by 10.216.198.27 with HTTP; Fri, 19 Nov 2010 17:49:55 -0800 (PST) In-Reply-To: References: <4CE50849.106@zedat.fu-berlin.de> Date: Fri, 19 Nov 2010 17:49:55 -0800 X-Google-Sender-Auth: Hg2MQh2qNfgfohc6PYyqzyksUxo Message-ID: From: Garrett Cooper To: Oliver Pinter Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Sat, 20 Nov 2010 03:05:00 +0000 Cc: FreeBSD Stable , freebsd-performance@freebsd.org, FreeBSD Current , "O. Hartmann" Subject: Re: TTY task group scheduling 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: Sat, 20 Nov 2010 01:49:58 -0000 On Fri, Nov 19, 2010 at 5:27 PM, Oliver Pinter wrote: > My desktop running 7-STABLE with 100Hz and NOPREEMPT (it's a 4core SMP system), > I tested 8-STABLE, but that is not too responsive, the solution is: > 100Hz NOPREEMPT + kern.sched.preempt_thresh=224 > After this setting, the system is likely responsive as 7-STABLE. > > On 11/19/10, Garrett Cooper wrote: >> On Fri, Nov 19, 2010 at 1:10 PM, Oliver Pinter >> wrote: >>> http://lkml.org/lkml/2010/11/16/392 >>> >>> On 11/18/10, O. Hartmann wrote: >>>> On 11/18/10 02:30, grarpamp wrote: >>>>> Just documenting regarding interactive performance things. >>>>> This one's from Linux. >>>>> >>>>> http://www.phoronix.com/scan.php?page=article&item=linux_2637_video&num=1 >>>> >>>> Well, >>>> it would be nice to have those improvements in FreeBSD, but I doubt this >>>> will make it in due time to FreeBSD's kernel. >> >> And my one line fix: >> >> renice 10 `pidof firefox-bin` >> >> Instantly my system is snappier (and in fact my system got really >> laggy after applying the preempt sysctl that everyone recommended >> before)... Performance issue with firefox maybe :P? I don't see the >> point of adding an additional layer to complicate the system (and >> essentially slow it down) if all you're trying to do is better >> describe the nice'ing problem, unless this logic is what you want to >> do strictly for desktop users in PCBSD, etc who may not have the >> technical wherewithal to accomplish this task. >> >> Besides, the Linux kernel has different compile time profiles for >> different workloads, so maybe it just works better for them because >> they already have a means for describing that functionality, whereas >> FreeBSD is more generic. >> >> It would be nice to describe this in a document though so people could >> also decide how to tune the system for themselves and not deal with a >> patch like what's noted above by the penguin crowd because it will >> invariably fail under some workloads or conditions (I have yet to see >> a one-size-fits-all solution in this area). >> >> >> SCHED_ULE improvements though should be looked into if possible, >> because there are some potential items that could be done to cluster >> processes together better, maybe. >> Ugh. Looks like this was the only machine that I setup recently where I didn't set kern.hz... Ok, will retry after building and installing a whole new world *queue lame Disney music here* and kernel. Thanks for the obvious reminder... -Garrett