Date: Tue, 13 Dec 2011 06:04:35 -0500 From: George Mitchell <george+freebsd@m5p.com> To: freebsd-stable@freebsd.org Subject: Re: SCHED_ULE should not be the default Message-ID: <4EE73143.5090100@m5p.com> In-Reply-To: <4EE6295B.3020308@cran.org.uk> References: <4EE1EAFE.3070408@m5p.com> <4EE22421.9060707@gmail.com> <4EE6060D.5060201@mail.zedat.fu-berlin.de> <20111212155159.GB73597@troutmask.apl.washington.edu> <4EE6295B.3020308@cran.org.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
On 12/12/11 11:18, Bruce Cran wrote: > On 12/12/2011 15:51, Steve Kargl wrote: >> This comes up every 9 months or so, and must be approaching FAQ >> status. In a HPC environment, I recommend 4BSD. Depending on the >> workload, ULE can cause a severe increase in turn around time when >> doing already long computations. If you have an MPI application, >> simply launching greater than ncpu+1 jobs can show the problem. PS: >> search the list archives for "kargl and ULE". > > This isn't something that can be fixed by tuning ULE? For example for > desktop applications kern.sched.preempt_thresh should be set to 224 from > its default. I'm wondering if the installer should ask people what the > typical use will be, and tune the scheduler appropriately. > I tried my "make buildkernel" test with "dnetc" running after setting kern.sched.preempt_thresh set to 224. It did far worse than before, getting only as far as compiling bxe overnight (compared to getting to netgragh with the default kern.sched.preempt_thresh setting). -- George Mitchell
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4EE73143.5090100>