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: the P2M/VP patch merge plan (was Re: [Xen-ia64-devel] [PATCH][RFC][T

To: Isaku Yamahata <yamahata@xxxxxxxxxxxxx>
Subject: Re: the P2M/VP patch merge plan (was Re: [Xen-ia64-devel] [PATCH][RFC][TAKE5] the P2M/VP patches)
From: Tristan Gingold <Tristan.Gingold@xxxxxxxx>
Date: Thu, 18 May 2006 09:48:54 +0200
Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Thu, 18 May 2006 00:44:49 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20060518051104.GC27665%yamahata@xxxxxxxxxxxxx>
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: <20060418141802.GG423%yamahata@xxxxxxxxxxxxx> <200605171615.38960.Tristan.Gingold@xxxxxxxx> <20060518051104.GC27665%yamahata@xxxxxxxxxxxxx>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: KMail/1.5
Le Jeudi 18 Mai 2006 07:11, Isaku Yamahata a écrit :
> On Wed, May 17, 2006 at 04:15:38PM +0200, Tristan Gingold wrote:
> > I'd just like to understand clearly why and where locks must be added.
> > Adding locks has a cost and must be understood in order to be done
> > correctly.
>
> Yes lock has a cost.
> If lockless approache was achieved, it would be a big win especially
> on a big iron.
> However are you really sure about all races?
> If there are a bug, it must rarely happen and be very nasty.
> It would be almost impossible to debug such a bug.
> Instead, a certain way should be adopted at first although
> its performance may be poor.
> Once stablilized, we should do performance tuning.
> Lockless aproach should be a one of the tuning candidates.
>
> I don't think lockless approach should be taken at the early stage,
> especially when perfomance optimization is planned.
> Since lockless code is very difficult to modify, trying another
> tuning idea becames very diffucalt.
I do not defend lockless approach.
I am just asking why should we add a lock if we don't have a race scenario.

Again, I don't have your experience on dom0 vp.  If you think a lock is 
required, feel free to add it.

Tristan.

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