linux-kernel - Re: Scheduler regression: Too frequent timer interrupts(?)

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]

Message-ID: <20090418073510.GI7678@elte.hu>
Date:	Sat, 18 Apr 2009 09:35:10 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Chris Friesen <cfriesen@...tel.com>
Cc:	Christoph Lameter <cl@...ux.com>,
	Peter Zijlstra <peterz@...radead.org>,
	linux-kernel@...r.kernel.org
Subject: Re: Scheduler regression: Too frequent timer interrupts(?)


* Chris Friesen <cfriesen@...tel.com> wrote:

> Christoph Lameter wrote:
>
>> The latencytest code simulates a busy processor (no system calls, all
>> memory is prefaulted). For some reasons Linux is increasingly taking time
>> away from such processes (that intentionally run uncontended on a
>> dedicated processor). This causes regressions so that current upstream is
>> not usable for these applications.
>>
>> It would be best for these applications if the processor would be 
>> left undisturbed. There is likely not much that the OS needs to 
>> do on a busy processor if there are no competing threads and if 
>> there is no I/O taking place.
>
> Peter/Ingo, could ftrace be used to determine where time is being 
> spent in the kernel with suitable accuracy?  (This may be a dumb 
> question, I haven't played with ftrace much.)

Yes, both ftrace and perfcounters can be used to directly trace or 
sample any overhead/delay - no matter how sporadic it might be.

> Given that we're talking about tens of usecs of duration, 
> statistical sampling may not work all that well.

Peter did rather convincing perfcounters profiles. Of course, if 
only maximum latencies are concerned, tracing works better. But 
mainline is pretty inadequate for that purpose anyway - there's a 
whole PREEMPT_RT world with many stories to tell there ;-)

	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/