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: <45F9AE1D.7080203@vmware.com>
Date:	Thu, 15 Mar 2007 13:35:41 -0700
From:	Dan Hecht <dhecht@...are.com>
To:	Rik van Riel <riel@...hat.com>
Cc:	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,
	schwidefsky@...ibm.com, Zachary Amsden <zach@...are.com>
Subject: Re: Stolen and degraded time and schedulers

On 03/15/2007 01:14 PM, Rik van Riel wrote:
> 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.

In the Xen and VMI case, the hypervisor differentiates between stolen 
and idle time, which is why we use the hack to call into 
account_steal_time with NULL tsk (so that all of steal gets accounted to 
stolen, even if the idle task happened to be current).  This allows us 
to account stolen time that happened on the tail end of an idle period.



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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ