TTY task group scheduling

[O. Hartmann]

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.