Date: Fri, 19 Nov 2010 09:33:23 +0000 From: David Xu <davidxu@freebsd.org> To: Lucius Windschuh <lwindschuh@googlemail.com> Cc: Bruce Cran <bruce@cran.org.uk>, freebsd-performance@freebsd.org Subject: Re: TTY task group scheduling Message-ID: <4CE64463.3050508@freebsd.org> In-Reply-To: <AANLkTinyvr70sNdmgZrxEXRuqQNeGR__=Yfs3iwWeRb4@mail.gmail.com> References: <AANLkTinHSX1%2Bs3hrHyDeU2Vfp6zekTe04XkHhTc2jtLv@mail.gmail.com> <4CE50849.106@zedat.fu-berlin.de> <4CE52177.3020306@freebsd.org> <AANLkTimq=5KJb5AGA6H0yA7AWrp%2BHZMRhfH6pnh=_NqA@mail.gmail.com> <20101118201644.00004c3c@unknown> <AANLkTinyvr70sNdmgZrxEXRuqQNeGR__=Yfs3iwWeRb4@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Lucius Windschuh wrote: > 2010/11/18 Bruce Cran <bruce@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 <bruce@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4CE64463.3050508>