linux-kernel - Re: [git pull] scheduler changes for v2.6.26

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, 22 Apr 2008 06:41:47 -0300
From:	Kevin Winchester <kjwinchester@...il.com>
To:	Ingo Molnar <mingo@...e.hu>
CC:	Frans Pop <elendil@...net.nl>, torvalds@...ux-foundation.org,
	linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Mike Galbraith <efault@....de>,
	Richard Jonsson <richie@...erworld.net>,
	"Rafael J. Wysocki" <rjw@...k.pl>
Subject: Re: [git pull] scheduler changes for v2.6.26

Ingo Molnar wrote:
> * Frans Pop <elendil@...net.nl> wrote:
> 
>>> It would be nice if you could try sched-devel/latest because it has 
>>> an improved ftrace "sched_switch" tracer where you can generate much 
>>> longer traces of this incident. Try the new /debug/trace_entries 
>>> runtime tunable.
>> I'll try to get the trace and will reply on the private thread we had. 
>> I may need additional instructions though.
> 
> you could also reply to this thread if you dont mind, so that others can 
> chime in too.
> 
> the 700-800 msecs of delays you see are very "brutal" so there must be 
> something fundamentally wrong going on here.
> 
> Could you first check (under sched-devel/latest) the quality of your 
> sched-clock, via running this script:
> 
>    http://people.redhat.com/mingo/cfs-scheduler/tools/watch-rq-clock.sh
> 
> if you run it, it should output ~1000 msecs periods every second:
> 
>  europe:~> watch-rq-clock.sh
>  1002.115042
>  1005.509851
>  1004.187275
>  1004.409980
>  1004.430264
>  1004.445508
> 
> if it's way too 'slow', say it only 100 msecs per second, then the 
> scheduler clock is mis-measuring time and what the scheduler thinks to 
> be a 40 msecs delay might become a 400 msecs delay.
> 

Is this supposed to be true for everyone?

kevin@...khine:~/linux$ uname -a
Linux alekhine 2.6.25-02519-g3925e6f #10 PREEMPT Sat Apr 19 12:36:49 ADT 2008 x86_64 GNU/Linux

kevin@...khine:~/linux$ ./watch-rq-clock.sh
89.986517
81.033471
76.942776
90.986318
75.988551
85.987089
74.988696
85.987078
73.988858
88.986641
68.989600

kevin@...khine:~/linux$ cat /proc/cpuinfo
processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 15
model           : 31
model name      : AMD Athlon(tm) 64 Processor 3000+
stepping        : 0
cpu MHz         : 1000.000
cache size      : 512 KB
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt lm 3dnowext 3dnow
rep_good lahf_lm
bogomips        : 2006.79
TLB size        : 1024 4K pages
clflush size    : 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management: ts fid vid ttp

Does that mean anything?  Is there any other testing I should perform?

-- 
Kevin Winchester
--
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/