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.
_______________________________________________
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
