* Matthew Hawkins <[email protected]> wrote:
> For the newly-tested kernel (-ck+sched_yield_hack) it was 4-5 seconds
> for initial load, same as CFS normally does for me. I think the 8
> second one was because I got in quick and the system was still running
> some startup crap (so I blame disk i/o not the scheduler). I'll keep
> an eye on it just in case, but hardly consider it a regression at this
> stage.
okay. If you suspect some regression then there are various ways to get
less subjective metrics of delays.
Firstly, you might want to look into desktop-action recorders to measure
precise latencies of on-desktop sequences that are important to you.
To get a 'cache cold' system you can do:
echo 1 > /proc/sys/vm/drop_caches
this zaps all the VM/vfs caches in the system, so you can do an
arbitrary number of cache-cold and cache-hot measurements as well.
Another source of information about desktop latencies is in the
/proc/<PID>/sched files if CONFIG_SCHED_DEBUG and CONFIG_SCHEDSTATS is
enabled. For example here's the delays of all my firefox threads:
$ grep max /proc/`pidof firefox-bin`/task/*/sched | sort -t: -k 3 -n | tail -10
/proc/3016/task/3041/sched:se.exec_max : 15865
/proc/3016/task/3031/sched:se.exec_max : 31604
/proc/3016/task/3032/sched:se.exec_max : 46892
/proc/3016/task/3032/sched:se.wait_max : 511850
/proc/3016/task/3016/sched:se.exec_max : 1013570
/proc/3016/task/3016/sched:se.block_max : 14870850
/proc/3016/task/3016/sched:se.wait_max : 32558799
/proc/3016/task/3016/sched:se.sleep_max : 87667199
/proc/3016/task/3032/sched:se.sleep_max : 430423009
/proc/3016/task/3031/sched:se.sleep_max : 1206545563
'sleep_max' values mean voluntary (interruptible) sleeps - those are
usually harmless and dont cause human-visible latencies. The 'dangerous'
ones are the block_max (maximum uninterruptible sleep - such as disk IO,
lock contention or swap activities) and wait_max (maximum time a task
got on the CPU) values.
In the above list the largest wait_max was 32.5 msecs (all CFS units are
in nanosecs), the largest block_max was 14.8 msecs - both are pretty OK.
(you can clear the stats and start the measurement anew by echo-ing 0 to
the /proc 'sched' files - without having to exit the app.)
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
