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]

Date:	Fri, 16 Mar 2007 09:59:01 +0100
From:	Martin Schwidefsky <schwidefsky@...ibm.com>
To:	Dan Hecht <dhecht@...are.com>
Cc:	Rik van Riel <riel@...hat.com>,
	Jeremy Fitzhardinge <jeremy@...p.org>, dwalker@...sta.com,
	cpufreq@...ts.linux.org.uk,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Con Kolivas <kernel@...ivas.org>,
	Chris Wright <chrisw@...s-sol.org>,
	Virtualization Mailing List <virtualization@...ts.osdl.org>,
	john stultz <johnstul@...ibm.com>, Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>, paulus@....ibm.com,
	Zachary Amsden <zach@...are.com>
Subject: Re: Stolen and degraded time and schedulers

On Thu, 2007-03-15 at 13:35 -0700, Dan Hecht wrote:
> >> Yes, the part in the "i.e." above is describing available time.  So, 
> >> it is essentially is the same definition of stolen time VMI uses:
> > 
> >> stolen time     == ready to run but not running
> >> available time  == running or not ready to run
> > 
> > S390 too.  We were quite careful to make sure that steal time
> > means the same on the different platforms when the code was
> > introduced.
> > 
> 
> The S390 folks should correct me if I'm mistaken, but I think S390 works 
> a bit differently.  I don't think their "steal clock" will differentiate 
> between idle time and stolen time (since it's implemented as a hardware 
> clock that counts the time a particular vcpu context is executing on the 
> pcpu).  So they need the kernel to differentiate between really stolen 
> time and just idle time.  At least, I assume this is why 
> account_steal_time() can then sometimes account steal time towards idle, 
> and looking at arch/s390/kernel/vtime.c seems to indicate this.
> idle period.

For s390 we have: stolen time == wanted to run but the hypervisor didn't
let us. The way this is implemented is by using the cpu timer. This is a
per-cpu register that is fully virtualized. It runs at the same rate as
the clock, but only if the virtual cpu is scheduled to run. If the real
cpu falls out of the guest context the guest cpu timer just stops. The
wall clock (TOD) keeps ticking. The calculation to find the amount of
stolen time is now simple: TOD clock - guest cpu timer.
For idle there is a little pitfall. If the guest cpu is a dedicated cpu
under LPAR loading a wait psw does not cause the guest cpu fall out of
the guest context. The guest cpu timer will continue ticking. In this
case the time spent in idle is accounted via system_time. If the guest
cpu is a shared cpu then loading a wait psw will cause the cpu to fall
out of guest context and the guest cpu timer will be stopped. In this
case the idle time will be accounted via steal_time. 

-- 
blue skies,              IBM Deutschland Entwicklung GmbH
   Martin                Vorsitzender des Aufsichtsrats: Johann Weihen
                         Geschäftsführung: Herbert Kircher
Martin Schwidefsky       Sitz der Gesellschaft: Böblingen
Linux on zSeries         Registergericht: Amtsgericht Stuttgart,
   Development           HRB 243294

"Reality continues to ruin my life." - Calvin.

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