WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-ia64-devel

Re: [Xen-ia64-devel] [RFC] grant table API clean up and performancetunin

Le Jeudi 27 Avril 2006 04:31, Isaku Yamahata a écrit :
[...]
> > Two questions:
> > It seems your mechanism still need to trust the domains.  So we need to
> > add checks for itc/ptc.
> >
> > However, can a granted page be mapped several times ?
> > If so, tracking is necessary and has a cost.
>
> Grant table API allows it. Xen tracks it by the counter(act->pin).
> However current xenLinux maps one-time per a granted page, I believe.
Even if it is mapped only once in guest physical memory, it may still be 
mapped many times in virtual memory.  True ?

> > From my point of view and my experience, flushing all the tlb/vhpt is
> > really costly (and even more with SMP-g), but it is necessary.
>
> The cost is very high.
>
> > Currently, we *don't* flush tlb/vhpt after unmapping granted page.  This
> > really creates instability (at least of gcc segfaults).
>
> My understanding is as follows.
> On the current P=M model, only dom0 maps/unmap granted pages.
> Because Dom0 accesses a granted page via machine address (given that m=p),
> flush isn't necessary.
> But the bug is there, there must be something I miss.
From my early tests, stability increase when tlb is flushed after umapping.
But this may be a side effect.

> > I don't have yet a magic solution.  I think we need to fix gcc segfault
> > bug first, and then we need to improve performance.
>
> I fully agree with you. Bug fix first, tuning next.
I am currently working on this.

Tristan.



_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel