Re: kern.sched.quantum: Creepy, sadistic scheduler

On 04/17/18 19:01, George Mitchell wrote: > On 04/17/18 17:20, EBFE via freebsd-stable wrote: >> [...] >> For interactive tasks, there is a "special" tunable: >> % sysctl kern.sched.interact >> kern.sched.interact: 10 # default is 30 >> % sysctl -d kern.sched.interact >> kern.sched.interact:

Re: kern.sched.quantum: Creepy, sadistic scheduler

19.04.2018 0:59, Peter wrote: > thank You very much for Your commenting and reports! > > From what I see, we have (at least) two rather different demands here: > while George looks at the over-all speed of compute throughput, others are > concerned about interactive response. > > My own

Re: kern.sched.quantum: Creepy, sadistic scheduler

Hi all of You, thank You very much for Your commenting and reports! From what I see, we have (at least) two rather different demands here: while George looks at the over-all speed of compute throughput, others are concerned about interactive response. My own issue is again a little bit

Re: kern.sched.quantum: Creepy, sadistic scheduler

EBFE via freebsd-stable wrote: On Tue, 17 Apr 2018 09:05:48 -0700 Freddie Cash wrote: # Tune for desktop usage kern.sched.preempt_thresh=224 ​Works quite nicely on a 4-core AMD Phenom-II X4 960T Processor (3010.09-MHz K8-class CPU) running KDE4 using an Nvidia 210 GPU.

Re: kern.sched.quantum: Creepy, sadistic scheduler

On 04/17/18 17:20, EBFE via freebsd-stable wrote: > On Tue, 17 Apr 2018 09:05:48 -0700 > Freddie Cash wrote: > >> # Tune for desktop usage >> kern.sched.preempt_thresh=224 >> >> ​Works quite nicely on a 4-core AMD Phenom-II X4 960T Processor >> (3010.09-MHz K8-class CPU)

Re: kern.sched.quantum: Creepy, sadistic scheduler

On Tue, 17 Apr 2018 09:05:48 -0700 Freddie Cash wrote: > # Tune for desktop usage > kern.sched.preempt_thresh=224 > > ​Works quite nicely on a 4-core AMD Phenom-II X4 960T Processor > (3010.09-MHz K8-class CPU) running KDE4 using an Nvidia 210 GPU. For interactive tasks,

Re: kern.sched.quantum: Creepy, sadistic scheduler

On Tue, Apr 17, 2018 at 8:49 AM, Kevin Oberman wrote: > On Mon, Apr 16, 2018 at 11:56 PM, Eivind Nicolay Evensen < > eivi...@terraplane.org> wrote: > > > On Wed, Apr 04, 2018 at 09:32:58AM -0400, George Mitchell wrote: > > > On 04/04/18 06:39, Alban Hertroys wrote: > > > >

Re: kern.sched.quantum: Creepy, sadistic scheduler

On Mon, Apr 16, 2018 at 11:56 PM, Eivind Nicolay Evensen < eivi...@terraplane.org> wrote: > 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 >

Re: kern.sched.quantum: Creepy, sadistic scheduler

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

Re: kern.sched.quantum: Creepy, sadistic scheduler

On 7/4/18 10:21 pm, Peter wrote: Julian Elischer wrote: 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. Julian, if we agree on this, I am fine. (This implies that SCHED_4BSD will *not* be

more data: SCHED_ULE+PREEMPTION is the problem (was: kern.sched.quantum: Creepy, sadistic scheduler

Hi all, in the meantime I did some tests and found the following: A. The Problem: --- On a single CPU, there are -exactly- two processes runnable: One is doing mostly compute without I/O - this can be a compressing job or similar; in the tests I used simply an endless-loop. Lets

Re: kern.sched.quantum: Creepy, sadistic scheduler

Julian Elischer wrote: 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. Julian, if we agree on this, I am fine. (This implies that SCHED_4BSD will *not* be retired for an indefinite time!) I

Re: kern.sched.quantum: Creepy, sadistic scheduler

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

Re: kern.sched.quantum: Creepy, sadistic scheduler

Eugene Grosbein wrote: I see no reasons to use SHED_ULE for such single core systems and use SCHED_BSD. Nitpicking: it is not a single core system, it's a dual that for now is equipped with only one chip, the other is in the shelf. But seriously, I am currently working myself through the

Re: kern.sched.quantum: Creepy, sadistic scheduler

04.04.2018 21:16, Peter wrote: > // 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

Re: kern.sched.quantum: Creepy, sadistic scheduler

Andriy Gapon wrote: Not everyone has a postgres server and a suitable database. Could you please devise a test scenario that demonstrates the problem and that anyone could run? Alright, simple things first: I can reproduce the effect without postgres, with regular commands. I run this on my

Re: kern.sched.quantum: Creepy, sadistic scheduler

Andriy Gapon wrote: On 04/04/2018 03:52, Peter wrote: Lets run an I/O-active task, e.g, postgres VACUUM that would continuousely read from big files (while doing compute as well [1]): Not everyone has a postgres server and a suitable database. Could you please devise a test scenario that

Re: kern.sched.quantum: Creepy, sadistic scheduler

On 04/04/2018 03:52, Peter wrote: > Lets run an I/O-active task, e.g, postgres VACUUM that would > continuousely read from big files (while doing compute as well [1]): Not everyone has a postgres server and a suitable database. Could you please devise a test scenario that demonstrates the problem

Re: kern.sched.quantum: Creepy, sadistic scheduler

On 04/04/18 10:34, Peter wrote: > [...] It does not make sense to me if now we state that > we cannot do it anymore because single-CPU is uncommon today. > [...] +1.-- George signature.asc Description: OpenPGP digital signature

Re: kern.sched.quantum: Creepy, sadistic scheduler

Hi Alban! Alban Hertroys wrote: Occasionally I noticed that the system would not quickly process the tasks i need done, but instead prefer other, longrunning tasks. I figured it must be related to the scheduler, and decided it hates me. If it hated you, it would behave much worse. Thats

Re: kern.sched.quantum: Creepy, sadistic scheduler

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,

Re: 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

Try setting kern.sched.preempt_thresh != 0 (was: Re: kern.sched.quantum: Creepy, sadistic scheduler)

Am 04.04.18 um 12:39 schrieb Alban Hertroys: > >> On 4 Apr 2018, at 2:52, Peter wrote: >> >> Occasionally I noticed that the system would not quickly process the >> tasks i need done, but instead prefer other, longrunning tasks. I >> figured it must be related to

Re: kern.sched.quantum: Creepy, sadistic scheduler

> On 4 Apr 2018, at 2:52, Peter wrote: > > Occasionally I noticed that the system would not quickly process the > tasks i need done, but instead prefer other, longrunning tasks. I > figured it must be related to the scheduler, and decided it hates me. If it hated

kern.sched.quantum: Creepy, sadistic scheduler

Occasionally I noticed that the system would not quickly process the tasks i need done, but instead prefer other, longrunning tasks. I figured it must be related to the scheduler, and decided it hates me. A closer look shows the behaviour as follows (single CPU): Lets run an I/O-active task,