RE: [PATCH 1/2] kvm/e500v2: Remove shadow tlb

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



 

> -----Original Message-----
> From: Hollis Blanchard [mailto:hollis_blanchard@xxxxxxxxxx] 
> Sent: Thursday, September 09, 2010 12:07 AM
> To: Liu Yu-B13201
> Cc: kvm@xxxxxxxxxxxxxxx; kvm-ppc@xxxxxxxxxxxxxxx; agraf@xxxxxxx
> Subject: Re: [PATCH 1/2] kvm/e500v2: Remove shadow tlb
> 
> On 09/08/2010 02:40 AM, Liu Yu wrote:
> > It is unnecessary to keep shadow tlb.
> > first, shadow tlb keep fixed value in shadow, which make 
> things unflexible.
> > second, remove shadow tlb can save a lot memory.
> >
> > This patch remove shadow tlb and caculate the shadow tlb entry value
> > before we write it to hardware.
> >
> > Also we use new struct tlbe_ref to trace the relation
> > between guest tlb entry and page.
> 
> Did you look at the performance impact?
> 
> Back in the day, we did essentially the same thing on 440. However, 
> rather than discard the whole TLB when context switching away 
> from the 
> host (to be demand-faulted when the guest is resumed), we found a 
> noticeable performance improvement by preserving a shadow TLB across 
> context switches. We only use it in the vcpu_put/vcpu_load path.
> 
> Of course, our TLB was much smaller (64 entries), so the use 
> model may 
> not be the same at all (e.g. it takes longer to restore a 
> full guest TLB 
> working set, but maybe it's not really possible to use all 1024 TLB0 
> entries in one timeslice anyways).
> 

Yes, it's hard to resume TLB0. We only resume TLB1 in previous code.
But TLB1 is even more smaller (13 free entries) than 440,
So that it still has little possibility to get hit.
thus the resumption is useless.

And we plan to use shadow PID to minimize the TLB invalidation.
Then we don't need to invalidate TLB when guest schedule out.
So that we don't need to resume TLB entries.

But thit method require dynamic TID in shadow TLB,
So we wouldn't like to keep shadow TLB anyway.

Thanks,
Yu

--
To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [KVM Development]     [KVM ARM]     [KVM ia64]     [Linux Virtualization]     [Linux USB Devel]     [Linux Video]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Big List of Linux Books]

  Powered by Linux