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 12:10, Isaku Yamahata a écrit :
> 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.
Yes, but what about the past history of the page.

> > 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?
This is just the same as tracking insert with the restriction of only one 
insert is allowed.

> > 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.
I think this is too late.
A page may have been already inserted before calling the constructor.
I think there is a security issue here.

> 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 will look closer.

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

Thank you for your comments,
Tristan.



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