freebsd stable - Apr 2018 - kern.sched.quantum: Creepy, sadistic scheduler

On 04/04/18 06:39, Alban Hertroys wrote:
> [...]
> That said, SCHED_ULE (the default scheduler for quite a while now) was
designed with multi-CPU configurations in mind and there are claims that
SCHED_4BSD works better for single-CPU configurations. You may give that a try,
if you're not already on SCHED_4BSD.
> [...]
A small, disgruntled community of FreeBSD users who have never seen
proof that SCHED_ULE is better than SCHED_4BSD in any environment
continue to regularly recompile with SCHED_4BSD.  I dread the day when
that becomes impossible, but at least it isn't here yet.      -- George

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20180404/214e136d/attachment.sig>

George Mitchell wrote:
> On 04/04/18 06:39, Alban Hertroys wrote:
>> [...]
>> That said, SCHED_ULE (the default scheduler for quite a while now) was
designed with multi-CPU configurations in mind and there are claims that
SCHED_4BSD works better for single-CPU configurations. You may give that a try,
if you're not already on SCHED_4BSD.
>> [...]
>
> A small, disgruntled community of FreeBSD users who have never seen
> proof that SCHED_ULE is better than SCHED_4BSD in any environment
> continue to regularly recompile with SCHED_4BSD.  I dread the day when
> that becomes impossible, but at least it isn't here yet.      -- George
>
Yes *laugh*, I found a very lengthy and mind-boggling discussion from 
back in 2011. And I found that You made this statement somewhere there:

// With nCPU compute-bound processes running, with SCHED_ULE, any other
// process that is interactive (which to me means frequently waiting for
// I/O) gets ABYSMAL performance -- over an order of magnitude worse
// than it gets with SCHED_4BSD under the same conditions. --
https://lists.freebsd.org/pipermail/freebsd-stable/2011-December/064984.html

And this describes quite exactly what I perceive.
Now, I would like to ask: what has been done about this issue?

P.

On 4/4/18 9:32 pm, George Mitchell wrote:
> On 04/04/18 06:39, Alban Hertroys wrote:
>> [...]
>> That said, SCHED_ULE (the default scheduler for quite a while now) was
designed with multi-CPU configurations in mind and there are claims that
SCHED_4BSD works better for single-CPU configurations. You may give that a try,
if you're not already on SCHED_4BSD.
>> [...]
> A small, disgruntled community of FreeBSD users who have never seen
> proof that SCHED_ULE is better than SCHED_4BSD in any environment
> continue to regularly recompile with SCHED_4BSD.  I dread the day when
> that becomes impossible, but at least it isn't here yet.      -- George
>
for a single CPU you really should compile a kernel with SMP turned 
off and 4BSD scheduler.

ULE is just trying too hard to do stuff you don't need.

On Wed, Apr 04, 2018 at 09:32:58AM -0400, George Mitchell
wrote:
> On 04/04/18 06:39, Alban Hertroys wrote:
> > [...]
> > That said, SCHED_ULE (the default scheduler for quite a while now) was
designed with multi-CPU configurations in mind and there are claims that
SCHED_4BSD works better for single-CPU configurations. You may give that a try,
if you're not already on SCHED_4BSD.
> > [...]
> 
> A small, disgruntled community of FreeBSD users who have never seen
> proof that SCHED_ULE is better than SCHED_4BSD in any environment
> continue to regularly recompile with SCHED_4BSD.  I dread the day when
> that becomes impossible, but at least it isn't here yet.      -- George
Indeed 4bsd is better in my case aswell. While for some unknown to me reason
ule performed a bit better in the 10.x series than before, in 11.x
it again is in my case not usable.

Mouse freezes for around half a second with even frequency by just moving
it around in x11. Using 4bsd instead makes the problem go away.
I'm actually very happy that ule became worse again because going
back to 4bsd yet again also gave improved performance from other
dreadfully slow but (to me) still useful programs, like darktable.

With 4bsd, when adjusting shadows and highlights it is possible to see what I
do when moving sliders. With ule it has never been better than waiting
10-20-30 seconds to see where it was able to read a slider position
and update display, when working on images around 10500x10500 greyscale.

It's not single cpu/single core either:
CPU: AMD FX(tm)-6300 Six-Core Processor              (3817.45-MHz K8-class CPU)




-- 
Eivind