Re: Bug/limitation in 'time' (kernel setings?)...

[Linda Walsh]

Linda Walsh wrote:
> 
> Bruce Dawson wrote:
>> How many CPUs do you have? 20% usage doesn't mean anything without knowing
>> that. On a five-core system 20% usage would imply one full core.
---
Another tool to check out if you have it is 'qps'... it can show the
time slice/schedule interval ... I can see it scheduling 24ms/ intervals for
bash when it runs a separate proc/loop.  It sounds a bit sketchy to me why
it would take 76ms for it to be scheduled for another run, but ... that's about
what it measures out it in real time.

The fact that your kernel doesn't show you that ... I don't know what to say,
other than it's how your kernel is configured.

Now looking in my /proc/sys/kernel

I see sched_latency_ns = 24000000 (24 ms).

I also see the scheduler doesn't wakup all the time:
but about every 4 ms.  (I inserted the commas):
proc/sys/kernel# for i in sched*;do
> echo $i: $(<$i)
> done
sched_autogroup_enabled: 1
sched_child_runs_first: 0
sched_domain:
sched_latency_ns: 24,000,000
sched_migration_cost_ns: 500,000
sched_min_granularity_ns: 3,000,000
sched_nr_migrate: 32
sched_rt_period_us: 1,000,000
sched_rt_runtime_us: 950,000
sched_shares_window_ns: 10,000,000
sched_time_avg_ms: 1000
sched_tunable_scaling: 1
sched_wakeup_granularity_ns: 4,000,000

So if the child runs first = 0, the parent keeps running at first,
If that latency of 24 is how long before the scheduler wakes up and
switches tasks, that 24 ms wasted, then same for child.  That's about
a 33% duty cycle there -- which can likely be tweaked by tweaking the above
numbers...