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 10:40, Isaku Yamahata a écrit :
> On Thu, Apr 27, 2006 at 09:34:54AM +0200, Tristan Gingold wrote:
> > 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 ?
>
> Yes, it's true.
> Usually only __va()'ed address is used.
That's certainly true for vbd.  For vnif, if the buffer is allocated from the 
slab, it may then be wrong.  For balloon, this is not true.

I am trying to understand what can be done to avoid global vtlb flush.

Tracking tlb insert is a possible solution, but has an high cost.

Enforcing one insert policy is an easier solution: each page granted may only 
be mapped once in virtual memory.  But this doesn't work for transfer.

I also suppose ballooning is not very frequent and thus global vtlb flush can 
be used when page are removed.  Is it correct ?

Tristan.




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