Re: Page fault is 4 times faster with XI shadow mechanism

[zhu <vanbas.han@gmail.com>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb18030; format=flowed, Size: 3386 bytes --]


Robert Phillips дµÀ:
> Well I don't.  I simply pre-allocate a pool of SPTI's.  It can be quite a
> large pool but certainly not one-SPTI per MFN.  SPTIs are allocated on
> demand (when a guest page needs to be shadowed) and, when the pool runs 
> low,
> the LRU SPTs are torn down and their SPTIs recycled.
> 
Well what I mean is that we should not connect a snapshot page with a 
SPTI at the first time the SPTIs are reserved. It would be better to 
manage these snapshot pages in another dynamic pool.
BTW: What do you think of the backlink issue mentioned in my previous mail?
> Currently I allocate about 5% of system memory for this purpose (this
> includes the SPT, its snapshot and the backlink pages) and, with that
> reasonable investment, we get very good performance.  With more study, I'm
> sure things could be tuned even better.  (I hope I have properly understood
> your questions.)
> 
> -- rsp
> 
> On 7/1/06, zhu <vanbas.han@gmail.com > wrote:
>>
>> Hi,
>> After taking some time to dig into your patch about XI Shadow page
>> table, I have to say it's really a good design and implementation IMHO,
>> especially the parts about the clear hierarchy for each smfn,decision
>> table and how to support 32nopae in a rather elegant way. However, I
>> have several questions to discuss with you.:-)
>> 1) It seems XI shadow pgt reserve all of the possible resources at the
>> early stage for HVM domain(the first time to create the asi). It could
>> be quite proper to reserve the smfns and sptis. However, do we really
>> need to reserve one snapshot page for each smfn at first and retain it
>> until the HVM domain is destroyed? I guess a large number of gpts will
>> not been modified frequently after them are totally set up. IMHO, it
>> would be better to manage these snapshot pages dynamic. Of course, this
>> will change the basic logistic of the code, e.g. you have to sync the
>> shadow pgt when invoke spti_make_shadow instead of leaving it out of
>> sync, you can't set up the total low level shadow pgt when invoke
>> resync_spte  since it could cost a lot of time.
>> 2) GP back link plays a very important role in XI shadow pgt. However,
>> it will also cause high memory pressure for the domain(2 pages for each
>> smfn). For these normal guest pages instead of GPT pages, I guess its
>> usage is limited. Only when invoke xi_invld_mfn, divide_large_page or
>> dirty logging, we will refer to the back link for these normal guest
>> pages. Is it reasonable to implement the back link only for the GPT
>> pages? Of course, this will increase the complexity of the code a little.
>> 3) Can you show us the statistics between the current shadow pgt and XI
>> pgt for some critical operations, such as shadow_resync_all, gva_to_gpa,
>> shadow_fault and so on. I'm really curious about it.
>>
>> I have to say I'm not very familiar with the current shadow pgt
>> implementation so I could miss some important considerations when I post
>> these questions. Please point it out.
>> Thanks for sharing your idea and code with us. :-)
>>
>> _______________________________________________________
>> Best Regards,
>> hanzhu
>>
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>>
> 
> 
>