From owner-freebsd-current@FreeBSD.ORG Sat Nov 20 01:28:04 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ED826106566B; Sat, 20 Nov 2010 01:28:03 +0000 (UTC) (envelope-from oliver.pntr@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 0A4C68FC1B; Sat, 20 Nov 2010 01:28:02 +0000 (UTC) Received: by wyb35 with SMTP id 35so4319483wyb.13 for ; Fri, 19 Nov 2010 17:28:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=tdNpb1QEuoGB8Gal23sGmrl4q11vEcMsiq1Tq+aaUCs=; b=u0m0jsJkKbk+PawPHQtsBK7Wbjd0FFQaEuPHUItchgBNsl6hKhmrEG8rsmwxhA//R4 dLj5ED+6p2cyR5BgHZ9JFGgl4E87LUZ6AVRRML9y/Zgau7r2WIaSYoN1QQtPZuxzlbIn be08Us0ADuPSQ9ogf8YFdSFMRXcah8QFw0mu8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=vnwp9t8j3YW/jfdYkbfTcGhsfFoF60wwhFRslJqdXzCGm5aT+1edxgw31BEiuZEkzS OkD6T9ovRkjzyIJPvbkQGDJcRkBXdWfuykK3utWAMLp7fgk0sne15u+CbF0615D5PeUW ZFmtg6rj5aPUuuYb6IY4luI5A04j2NlJCYDwI= MIME-Version: 1.0 Received: by 10.227.157.133 with SMTP id b5mr3103975wbx.53.1290216480334; Fri, 19 Nov 2010 17:28:00 -0800 (PST) Received: by 10.227.133.66 with HTTP; Fri, 19 Nov 2010 17:27:59 -0800 (PST) In-Reply-To: References: <4CE50849.106@zedat.fu-berlin.de> Date: Sat, 20 Nov 2010 02:27:59 +0100 Message-ID: From: Oliver Pinter To: Garrett Cooper Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Stable , freebsd-performance@freebsd.org, FreeBSD Current , "O. Hartmann" Subject: Re: TTY task group scheduling X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Nov 2010 01:28:04 -0000 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. > > > Thanks, > -Garrett >