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

[Isaku Yamahata <yamahata@xxxxxxxxxxxxx>]

On Thu, Apr 27, 2006 at 11:20:04AM +0200, Tristan Gingold wrote:
> 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. 

The Linux slab allocater returns __va()'ed addresses.
So it isn't worng.


> For balloon, this is not true.

I agree.
It can't be tell for what purpose pages that get_free_pages() gives is used
before in general.


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

I'm not sure tracking cost.
All of tlb inserts need not be tracked.
Only tlb inserts associated to a granted page need to be tracked.


> Enforcing one insert policy is an easier solution: each page granted may only
> be mapped once in virtual memory. 

I don't understand why "enforceing one insert policy" is easier than
tracking tlb insert.
All of virtual addresses associated to a page need not be tracked.
If more than one (or some threshould) virtual addresses are used
for a page, it can be marked and fall back into full flush.

Maybe I don't understant what "enforceing one insert policy" is.
Could you elabolate?


> But this doesn't work for transfer.

As you mentioned above, pages used for transfer is allocated
from the slab.
The Linux slab allocater calls constructor/destructor.
It's easy to register pages used for socket buffer to xen/ia64 in order
to track tlb inserts.
Please see skbuff_cotr() in linux-2.6-xen-sparse/drivers/xen/core/skbuff.c.
If an unregister page is transfered, fall back into full flush.


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

I agree with respect to the frequency.
If the frequency is high, page freeing in xen can be deferred by queueuing.
A domain requests pages again, pages can be get from the queue.
If the queue becomes long or memory puressure in xen becomes high,
free pages in the queue after flush.

-- 
yamahata

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