linux-kernel - Re: How how latent should non-preemptive scheduling be?

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 for Android: free password hash cracker in your pocket

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

Date:	Thu, 18 Sep 2008 19:25:21 +0100
From:	Sitsofe Wheeler <sitsofe@...oo.com>
To:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
CC:	Arjan van de Ven <arjan@...radead.org>,
	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...e.hu>
Subject: Re: How how latent should non-preemptive scheduling be?

Peter Zijlstra wrote:
> What you can do to investigate this, is use the sched_wakeup tracer from
> ftrace, that should give a function trace of the highest wakeup latency
> showing what the kernel is doing.

I struggled to find documentation of ftrace because it's quite new. I 
have come across 
http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_MRG/1.0/html/Realtime_Tuning_Guide/sect-Realtime_Tuning_Guide-Realtime_Specific_Tuning-Using_the_ftrace_Utility_for_Tracing_Latencies.html 
and 
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/ftrace.txt;h=d330fe3103da9c9a3cb8f888ac7255ce48e666d4;hb=45e9c0de2e86485f8b6633fd64ab19cfbff167f6 
  .

Thanks to those I started up the debugfs filesystem and went to the 
trace directories but the on tracers in available_tracers are
ftrace sched_switch none

I can't see anything in the code that would disable wakeup... Any ideas 
on what might be wrong? I'm using a 2.6.27rc6 kernel.

Additionally I think I found a trigger - unplugging the power cable from 
the EeePC and having it run on battery seems to then set off this 
periodic stall every 30 seconds... There's no CPU frequency scaling 
enabled either (Celeron M's seemingly don't have P states and support 
for cpufreq is configured out).

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