Lucius Windschuh wrote:
2010/11/18 Bruce Cran <br...@cran.org.uk>:
Have you tried increasing kern.sched.preempt_thresh? According to
http://groups.google.com/group/mailing.freebsd.stable/browse_thread/thread/05a39f816fd8acc6/82affa9f195b747d?lnk=raot&fwc=1&pli=1
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 <br...@cran.org.uk>:
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.
Regards,
David Xu
_______________________________________________
freebsd-performance@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "freebsd-performance-unsubscr...@freebsd.org"
