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] PATCH: cleanup of tlbflush

To: "Tian, Kevin" <kevin.tian@xxxxxxxxx>, <xen-ia64-devel@xxxxxxxxxxxxxxxxxxx>, "Magenheimer, Dan \(HP Labs Fort Collins\)" <dan.magenheimer@xxxxxx>, "Alex Williamson" <alex.williamson@xxxxxx>
Subject: Re: [Xen-ia64-devel] PATCH: cleanup of tlbflush
From: Tristan Gingold <Tristan.Gingold@xxxxxxxx>
Date: Wed, 10 May 2006 12:46:49 +0200
Delivery-date: Wed, 10 May 2006 03:42:47 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <571ACEFD467F7749BC50E0A98C17CDD8094E7BF8@pdsmsx403>
List-help: <mailto:xen-ia64-devel-request@lists.xensource.com?subject=help>
List-id: Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
List-post: <mailto:xen-ia64-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=unsubscribe>
References: <571ACEFD467F7749BC50E0A98C17CDD8094E7BF8@pdsmsx403>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: KMail/1.5
Le Mercredi 10 Mai 2006 11:14, Tian, Kevin a écrit :
> From: Tristan Gingold [mailto:Tristan.Gingold@xxxxxxxx]
>
> >Sent: 2006年5月10日 16:53
> >
> >> >> At least one simple enhancement
> >> >> we can do is to change syntax of domain_dirty_cpumask. We can
> >> >> change it to indicate processors that domain is ever running on.
> >
> >Then
> >
> >> >> update point only happens at creation/destroy/migration, or even
> >> >> pause/unpause. Though this simple strategy is not fine-grained, we
> >> >> can still achieve benefit especially when domain is bound.
> >> >
> >> >One use of domain_dirty_cpumask is to flush vtlb when a page is
> >> >ungranted.
> >> >If this mask is ever set, doing IOs trash the machine.
> >> >IMHO, this is the next major Xen/ia64 challenge: dealing correctly
> >
> >with
> >
> >> >granted page.
> >>
> >> Not clear about this one. Could you elaborate more? How dose IO
> >
> >cause
> >
> >> to trash the machine?
> >
> >[By trashing I mean slowing down].
> >The current common code calls flush_tlb_mask after ungranting a page.
> >On xen/ia64, flush_tlb_mask should flush the tlb and the vhpt, which
> >means
> >clearing 16MB per vcpu.  This is quiet high.
> >Unfortunatly, flushing is required for correctness.  The current Isaku
> >work-around is to reduce VHPT size (64Kb).  But even with a small
> >size,
> >flushing tlb requires an IPI when SMP-g, which is quiet slow.
> >
> >Tristan.
>
> I see your concern about flush efficiency. However we still need set
> necessary mask bits for correctness, right? 
Not yet, because pages are not transfered.

> It would be difficult to track
> exact processors which have footprint about different ungranted pages.
> To track that list may instead pull down performance at other places.
> Then to set domain_dirty_cpumask as ones that domain is currently
> running on, can be a simple/safe way in current stage though
> performance may be affected.
Unfortunatly performance are so badly affected that using SMP-g is useless!

Tristan.

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