linux-kernel - Re: Stolen and degraded time and schedulers

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:	Wed, 14 Mar 2007 12:44:15 -0700
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	Daniel Walker <dwalker@...sta.com>
CC:	john stultz <johnstul@...ibm.com>, Andi Kleen <ak@...e.de>,
	Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>,
	Con Kolivas <kernel@...ivas.org>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Zachary Amsden <zach@...are.com>,
	James Morris <jmorris@...ei.org>,
	Chris Wright <chrisw@...s-sol.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	cpufreq@...ts.linux.org.uk,
	Virtualization Mailing List <virtualization@...ts.osdl.org>,
	Peter Chubb <peterc@...ato.unsw.edu.au>
Subject: Re: Stolen and degraded time and schedulers

Daniel Walker wrote:
> sched_clock is used to bank real time against some specific states
> inside the scheduler, and no it doesn't _just_ measure a processes
> executing time.
>   

Could you point these places out?  All uses of sched_clock() that I
could see in kernel/sched.c seemed to be related to working out how long
something spent executing, either in the scheduler proper, or
benchmarking cache characteristics.

>>    1. If the cpu is stolen by the hypervisor, the kernel will get no
>>       state transition notification.  It can generally find out that
>>       some time was stolen after the fact, but there's no specific event
>>       at the time it happens.
>>     
>
> The hypervisor would need to do it's own accounting I'd imagine then
> provide that to the scheduler.
>   

Yes.  Xen, at least, provides nanosecond resolution information about
how long each vcpu spent in its various states.  But the question is how
this information should be exposed to the scheduler.  I could provide a
raw dump of the info, but in general the scheduler doesn't care and
other hypervisors might not be able to produce the same information. 
The essential information is "how long did process X actually run on a
real CPU"?  And that, as far as I can tell, is the question
sched_clock() is already designed to answer.

>>    2. It doesn't map particularly well to a cpu changing speed.  In
>>       particular if a cpu has continuously varying execution speed
>>       (Transmeta?), then the best you can hope for is the integration of
>>       cpu work done over a time period rather than discrete cpu
>>       speed-change events.
>>     
>
> True, but as I said in my original email it's not trivial to follow
> physical cpu speed changes since the changes are free form and change
> potentially per system. Your better off do it just with the hypervisor
> since you can control it ..
>   

No, I'm talking about cpu speed changes as a completely separate case,
which is primarily an issue while running a kernel on bare hardware. 
But it is, in some ways, more complex than running on a hypervisor. 
There are numerous mechanisms for cpu speed control, some kernel driven,
some autonomous, some stepwise, some continuous.  I'm arguing that its
the cpufreq subsystem's job to keep track of all that detail, but the
only information it needs to provide to the scheduler is, again, "how
much work did my process get done on the CPU"?

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