From mboxrd@z Thu Jan 1 00:00:00 1970 From: zhu Subject: Re: Page fault is 4 times faster with XI shadow mechanism Date: Sun, 02 Jul 2006 12:20:49 +0800 Message-ID: <44A749A1.3090705@gmail.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=gb18030; format=flowed Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Robert Phillips Cc: Xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org Robert Phillips =D0=B4=B5=C0: > 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= =20 > low, > the LRU SPTs are torn down and their SPTIs recycled. >=20 Well what I mean is that we should not connect a snapshot page with a=20 SPTI at the first time the SPTIs are reserved. It would be better to=20 manage these snapshot pages in another dynamic pool. BTW: What do you think of the backlink issue mentioned in my previous mai= l? > 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 unders= tood > your questions.) >=20 > -- rsp >=20 > 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, thi= s >> 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 eac= h >> 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 litt= le. >> 3) Can you show us the statistics between the current shadow pgt and X= I >> pgt for some critical operations, such as shadow_resync_all, gva_to_gp= a, >> 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 po= st >> 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 >> >=20 >=20 >=20