Re: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)

[Ingo Molnar <mingo@elte.hu>]

* Matthew Hawkins <darthmdh@gmail.com> 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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/