Try setting kern.sched.preempt_thresh != 0

Peter pmc at citylink.dinoex.sub.org
Wed Apr 4 14:35:05 UTC 2018


Stefan Esser wrote:
>
> I'm guessing that the problem is caused by kern.sched.preempt_thresh=0, which
> prevents preemption of low priority processes by interactive or I/O bound
> processes.
>
> For a quick test try:
>
> # sysctl kern.sched.preempt_thresh=1

Hi Stefan,

thank You, thats an interesting knob! Only it is actually the other way 
round: it is not set to 0. My settings (as default) are:

kern.sched.steal_thresh: 2
kern.sched.steal_idle: 1
kern.sched.balance_interval: 127
kern.sched.balance: 1
kern.sched.affinity: 1
kern.sched.idlespinthresh: 157
kern.sched.idlespins: 10000
kern.sched.static_boost: 152
kern.sched.preempt_thresh: 80
kern.sched.interact: 30
kern.sched.slice: 12
kern.sched.quantum: 94488
kern.sched.name: ULE
kern.sched.preemption: 1
kern.sched.cpusetsize: 4

But then, if I change kern.sched.preempt_thresh to 1 *OR* 0, things 
behave properly! Precisely, changing from 8 down to 7 changes things 
completely:

 >pool        alloc   free   read  write   read  write
 >cache           -      -      -      -      -      -
 >  ada1s4    7.08G  10.9G    927      0  7.32M      0

 >  PID USERNAME   PRI NICE   SIZE    RES STATE    TIME    WCPU COMMAND
 > 1900 pgsql       82    0   618M 17532K RUN      0:53  34.90% postgres
 > 1911 admin       81    0  7044K  2824K RUN      6:07  28.34% bash

(Notice the PRI values which also look differnt now.)

rgds,
P.


More information about the freebsd-stable mailing list