TTY task group scheduling
ohartman at zedat.fu-berlin.de
Fri Nov 19 10:19:44 UTC 2010
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<areilly at bigpond.net.au> 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.
More information about the freebsd-performance