Re: [PATCH 00/10] in-kernel APIC v3 (kernel side)

[Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org>]

Gregory Haskins wrote:

  

>> A good test is to let Windows boot and idle itself, then compare the 
>> process cpu time under the TIME+ column with model- 0 and model- 1.
>>     
>
> Will do.  One that that I notice that I can't explain yet is as follows:
>
> When I boot windows + level-1, the point at which windows is running in 16 bit real-mode in the very beginning (before the splashscreen comes up), we seem to take a very large number of exits for instruction emulation.  This ends up being a little storm of activity for about 1 second or so.  I am not really sure why this happens with the new code and not with the old.  It doesnt seem to hurt anything other than extra CPU used.  But its weird nonetheless. 
>
>   

Very strange. Maybe it is a problem with emulating the apic disabled 
mode. Or maybe the initial state of the apic is different between qemu 
and kvm+apic.

>> Since the vast majority of exits in the scenario are hitting the tpr, 
>> I'd be unsurprised if the time if 50% lower or so.
>>     
>
> Yeah, the new code essentially converts all those TPR exits to lightweight.  Nothing more, nothing less.  I could be crazy, but my perception is the GUI is *much* more responsive because of it, however.  Windows draw very fast and it actually seems usable.  Whereas trunk+ACPI always feels sluggish.  I don't know of a good benchmark to run to see if there really is an improvement, however.
>   

Just the cpu time spent during boot would be a good indication.

-- 
error compiling committee.c: too many arguments to function


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/