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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 31 Jul 2007 18:45:38 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Matthew Hawkins <darthmdh@...il.com>
Cc:	Kenneth Prugh <ken69267@...il.com>, ck@....kolivas.org,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Kasper Sandberg <lkml@...anurb.dk>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)

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