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

[Tristan Gingold <Tristan.Gingold@xxxxxxxx>]

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