FAULTvcpu = 0x pid = 0x11ea [ errorcode =
0x0009, virt = 0x fffb6d30 ]
Avi Kivity wrote:
> David S. Ahern wrote:
>> I have been looking at RHEL3 based guests lately, and to say the least
>> the
>> performance is horrible. Rather than write a long tom
I am trying to add a trace marker and the data is coming out all 0's. e.g.,
0 (+ 0) PTE_WRITE vcpu = 0x0001 pid = 0x240d [ gpa =
0x gpte = 0x ]
Patch is attached. I know the data is non-zero as I added an if check before
calling the trace to o
inline.
Liu, Eric E wrote:
> David S. Ahern wrote:
>> I am trying to add a trace marker and the data is coming out all 0's.
>> e.g.,
>>
>> 0 (+ 0) PTE_WRITE vcpu = 0x0001 pid = 0x240d [
>> gpa = 0x gpte = 0x
DOH. I had the 2 new ones backwards in the formats file.
thanks for pointing that out,
david
Liu, Eric E wrote:
>
> I mean the value of PTE_WRITE you write in the formats file ( 0x00020016
> )should be same with KVM_TRC_PTE_WRITE you define in kvm.h,
> but now it is 0x00020015. if not what yo
I added the traces and captured data over another apparent lockup of the guest.
This seems to be representative of the sequence (pid/vcpu removed).
(+4776) VMEXIT [ exitcode = 0x, rip = 0x c016127c ]
(+ 0) PAGE_FAULT [ errorcode = 0x0003, virt = 0x c0009
vmlinux free_hot_cold_page
david
Avi Kivity wrote:
> David S. Ahern wrote:
>> I added the traces and captured data over another apparent lockup of
>> the guest.
>> This seems to be representative of the sequence (pid/vcpu removed).
>>
>> (+4776) VMEXIT [ exitcode
ry_caches() and emulate_instruction() were both run 214,270 times,
most of them relatively quickly.
Note: I bumped the scheduling priority of the qemu threads to RR 1 so that few
host processes could interrupt it.
david
Avi Kivity wrote:
> David S. Ahern wrote:
>> I added the traces and captured da
>> Avi Kivity wrote:
>>
>>> David S. Ahern wrote:
>>>
>>>> I added the traces and captured data over another apparent lockup of
>>>> the guest.
>>>> This seems to be representative of the sequence (pid/vcpu removed).
>>&
Avi Kivity wrote:
>
> Ah! The flood detector is not seeing the access through the
> kmap_atomic() pte, because that access has gone through the emulator.
> last_updated_pte_accessed(vcpu) will never return true.
>
> Can you verify that last_updated_pte_accessed(vcpu) indeed always
> returns f
eally) is what the 0xfffb63b0 corresponds to in the guest. Any
ideas?
Also, the expensive page fault occurs on errorcode = 0x000b (PAGE_FAULT
trace data). What does the 4th bit in 0xb mean? bit 0 set means
PFERR_PRESENT_MASK is set, and bit 1 means PT_WRITABLE_MASK. What is bit 3?
david
Da
David S. Ahern wrote:
> Avi Kivity wrote:
>
>> David S. Ahern wrote:
>>
>>> I added the traces and captured data over another apparent lockup of
>>> the guest.
>>> This seems to be representative of the sequence (pid/vcpu removed).
>>>
&g
l paths leading to those functions. Any insights
would definitely be appreciated.
david
Marcelo Tosatti wrote:
> On Fri, Apr 25, 2008 at 11:33:18AM -0600, David S. Ahern wrote:
>> Most of the cycles (~80% of that 54k+) are spent in paging64_prefetch_page():
>>
>>
oblem.
Alternatively, during the hang on a restart I can kill the guest, and then on
restart choose the normal, 32-bit smp kernel and the guest boots just fine. At
this point I can shutdown the guest and restart with the hugemem kernel and it
boots just fine.
david
David S. Ahern wrote:
> Hi
Avi Kivity wrote:
> David S. Ahern wrote:
>> Another tidbit for you guys as I make my way through various
>> permutations:
>> I installed the RHEL3 hugemem kernel and the guest behavior is *much*
>> better.
>> System time still has some regular hiccups that are h
entos/3/isos/i386/
I am running RHEL3.8 which I do not see listed. Also, I'll need to work on a
stock install and try to capture some kind of workload that exhibits the
problem. It will be a couple of days.
david
Daniel P. Berrange wrote:
> On Wed, Apr 30, 2008 at 07:39:53AM -0600, David S
That does the trick with kscand.
Do you have recommendations for clock source settings? For example in my
test case for this patch the guest gained 73 seconds (ahead of real
time) after only 3 hours, 5 min of uptime.
thanks,
david
Avi Kivity wrote:
> Avi Kivity wrote:
>> Avi Kivity wrote:
>>>
Avi Kivity wrote:
> Not so fast... the patch updates the flood count to 5. Can you check
> if a lower value still works? Also, whether updating the flood count to
> 5 (without the rest of the patch) works?
>
> Unconditionally bumping the flood count to 5 will likely cause a
> performance regres
Avi Kivity wrote:
>
> Okay, I committed the patch without the flood count == 5.
>
I've continued testing the RHEL3 guests with the flood count at 3, and I
am right back to where I started. With the patch and the flood count at
3, I had 2 runs totaling around 24 hours that looked really good. No
I have been looking at RHEL3 based guests lately, and to say the least the
performance is horrible. Rather than write a long tome on what I've done and
observed, I'd like to find out if anyone has some insights or known problem
areas running 2.4 guests. The short of it is that % system time spikes
19 matches
Mail list logo
