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