From owner-freebsd-performance@FreeBSD.ORG Fri Nov 19 10:19:44 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 D32711065670 for ; Fri, 19 Nov 2010 10:19:44 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 89C8F8FC14 for ; Fri, 19 Nov 2010 10:19:44 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1PJO4E-0007hl-L5>; Fri, 19 Nov 2010 11:19:42 +0100 Received: from telesto.geoinf.fu-berlin.de ([130.133.86.198]) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1PJO4E-0006Mr-Fe>; Fri, 19 Nov 2010 11:19:42 +0100 Message-ID: <4CE64F42.1060006@zedat.fu-berlin.de> Date: Fri, 19 Nov 2010 11:19:46 +0100 From: "O. Hartmann" Organization: Freie =?ISO-8859-1?Q?Universit=E4t_Berlin?= User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Thunderbird/3.1.6 MIME-Version: 1.0 To: Bruce Cran References: <4CE50849.106@zedat.fu-berlin.de> <4CE52177.3020306@freebsd.org> <20101118182324.GA36312@freebsd.org> <20101119044129.GA4063@johnny.reilly.home> <20101119094652.00003652@unknown> In-Reply-To: <20101119094652.00003652@unknown> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: 130.133.86.198 Cc: Alexander Best , freebsd-performance@freebsd.org, Andriy Gapon , Andrew Reilly 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: Fri, 19 Nov 2010 10:19:44 -0000 On 11/19/10 10:46, Bruce Cran wrote: > [removed current@ and stable@ from the Cc list] > > On Fri, 19 Nov 2010 15:41:29 +1100 > Andrew Reilly wrote: > >> On Linux. Have you ever seen those sorts of UI problems on FreeBSD? >> I don't watch much video on my systems, but I haven't seen that. >> FreeBSD has always been good at keeping user-interactive processes >> responsive while compiles or what-not are going on in the background. > > I've definitely seen problems when running builds in an xterm. I've > often resorted to canceling it and running it on a syscons console > instead to improve performance. > A simple test: use X11, simply use windowmaker as the GUI (this is my configuration on most FreeBSD boxes around here in use for scientidic duties). The simply update your siurce tree via 'svn update' and warch responsivenes of your desktop. Or try start building world AND do something other, like building a big port like something from Qt4. I realize hangs and stuttering on the following FreeBSD OS' and hardware: FreeBSD 8.1-STABLE/amd64: box with 8 GB RAM, Intel Q6600 4-core CPU, UFS2 filesystem containing root. Another box 4 GB RAM, Intel E8400 2-core CPU, also UFS2 as the base filesystem. Both boxes use X11. The next box is our number crunching server, DELL Poweredge1950III, 16 GB RAM, two CPU XEON hw.model: Intel(R) Xeon(R) CPU E5420 @ 2.50GHz. No GUI. Base filesystem on which is build done: UFS2. These boxes have a significant 'stutter' and hang, when starting updating source tree or start building the base system, visible on each xterm or ssh session connected to the box (this is for the server which has no GUI). FreeBSD 9.0-CURRENT/amd64: Notebook, 4GB RAM, CPU: Intel Core i-5 with 2,4 GHz. Base filesystem UFS2, graphical device nVidia XM3100 with nVidia most reent 64bit BLOB driver for this kind of hardware. On the notebook the drop in performance and responsivenes is amazing, the box is 'dead' for a minute when doing 'svn update' for the source tree. I do not know whether those hangs are due to the topic of this thread, I doubt it is more due to a weakness of the I/O subsystem dealing with harddrives (I see hangs while on heavy load also on our ZFS homes). Since our institute uses several Linux flavors around here of several revisions I have some 'naive' comparisons. Even on heavy I/O load Linux does respond nicely. Our 8 core FreeBSD box runs some modelling software for astrodynamics, the software is 'serial', not yet parallelized, but even utilizing 6 out of 8 cores and push them under heavy load does not bother the system and the server responding is good. But any kind of heavy HD I/O, even if this job utilizes only one CPU (as far as I can guess), it gets worse.