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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <45F841EE.6060703@goop.org>
Date:	Wed, 14 Mar 2007 11:41:50 -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:
> >From prior emails I think your suggesting that 1ms (or 5 or 10) of time
> should actually be a variable X that is changed inside sched_clock().
> That's not the purpose of that API call, sched_clock() measure real time
> period.
>   

To what purpose?  What is it really measuring?  My understanding is that
its for the scheduler to work out how much time a process actually ran
for.  Aside from its use in printk as a general monotonic timestamp,
this seems to be how it gets used everywhere.  If I change it to return
cpu-ns (ie, make it not count time that the cpu was stolen by the
hypervisor), then it will return what its callers actually want to know.

If I scale its result according to the cpu's current speed compared to
its maximum speed, it would also be producing results consistent with
what its callers want to know.

> After reading your emails it sounds like what you really want is similar
> to accurate state accounting which is used for scheduling purposes. Part
> of that has already been implemented at least twice that I know of.
> Accounting real time against specific states was done in two version of
> microstate accounting. Those are fine starting points for the changes
> you are wanting.

I haven't looked at the microstate accounting patches in any detail, but
I'm assuming that they take a timestamp at each CPU state transition and
use that to account time to the appropriate entities (tell me if I'm
missing something pertinent here).  There are two problems with that
approach in this case:

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

    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/