TTY task group scheduling

David Xu davidxu at
Fri Nov 19 01:33:21 UTC 2010

Lucius Windschuh wrote:
> 2010/11/18 Bruce Cran <bruce at>:
>> Have you tried increasing kern.sched.preempt_thresh? According to
>> a good value for desktop use would be 224.
> Hmm, I though I tried this -- but this helps indeed. :-)
> The browser, movie player etc. behave much better when a "make -j4
> buildworld" is running on my 2-core machine in the background. Thank
> you.
> 2010/11/18 Bruce Cran <bruce at>:
>> If you're using UFS, I've found it to be quite a bottleneck when
>> doing parallel IO: I even ran a "svn up" in one terminal and tried to
>> login on another a couple of days ago only to find the motd took over 5
>> seconds to appear! That may be excessive since I was running a kernel
>> with WITNESS and INVARIANTS, but I've found ZFS to be far better if you
>> want good interactivity when reading/writing to disks.
> This is indeed another issue, which I also encountered, but explicitly
> left out since I don't blame the task scheduler for that. ;)
> Unfortunately, I don't know how much SCHED_ULE's inability to cope
> with more runnable threads than cores, as Steve mentioned, accounts to
> the problem I observe. Time to switch back to SCHED_4BSD? *sigh*
> Lucius

Sometimes, I am thinking that our thread scheduler should be split
into two layers, looks like Solaris did, the sched_ule really should
only be responsible for CPU dispatching, it only cares where a thread
should be dispatched based on CPU-affinity, each CPU's load, ...
Another layer is how to calculate thread's priority for time-sharing
thread, you can specify which priority algorithm to used, static
or dynamic priority scheduling, ULE's algorithm or 4BSD.
with cpuset, one even can bind all real-time processes to a specific
cpu group, they needn't to be a superuser to run real-time thread.

David Xu

More information about the freebsd-performance mailing list