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

Re: [Xen-devel] pthread_mutex_lock() and Xenstored

To: "Daniel P. Berrange" <berrange@xxxxxxxxxx>, "Vincent Hanquez" <vincent@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] pthread_mutex_lock() and Xenstored
From: "Peter Teoh" <htmldeveloper@xxxxxxxxx>
Date: Sat, 15 Sep 2007 14:01:12 +0800
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Fri, 14 Sep 2007 23:01:50 -0700
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=hEZCQeiqARg8wp+YPs/QnTn4RMin/qKCxYr92C1Z1vE=; b=kgHRN/lwqNckOTONJLVNkjXgJBYCsGvnLk5VsQVAt7Kz7p7QT1f2ocu01eNsuQOihUhBDioCSgaTWMA30A4cJXCXdnkhWbQtet53ALaT3W//6SPOCa9UAtfql8obEanyT/z+byXkgRVPVTfdKd3rOY5HrW58Bn5atdjBa1mMkYQ=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=cA464djWxsRMgOo/+tiEoyBA3aaHeLSK3N/iJAa7SzxQ43S1Zpb1I4CPof42e0RsBRL+8wYin9kBGsV+Jo2vaJIbLWEg7MZ8tCL0oca5IYzBqP5hWvgtbasPeFHIgjklvf6RYhRibUJ/y8skyMBnJEv/jIP/3Ib6wvePdeFCL78=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20070913152140.GF23525@xxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <05c801c7eb94$850ae780$9a010a0a@eeyore> <20070913152140.GF23525@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thank you for your feedback.   I am still learning these stuff.

On 9/13/07, Daniel P. Berrange <berrange@xxxxxxxxxx> wrote:
> On Fri, Aug 31, 2007 at 01:51:18PM +0800, Peter Teoh wrote:
> > pthread_mutex_lock() are not async-signal safe (ref:
> > http://www.gelato.org/pdf/Illinois/gelato_IL2004_libatomic_boehm.pdf)
> > but I still see that it is used extensively in xenstored implementation
> > (eg, xs.c).
>
> So what ?  The pthread_mutex_lock calls aren't used inside any signal
> handlers, so the question of whether its async-signal safe is irrelevant
>
> > Moreover, pthread_mutex_lock() suffered a higher performance penalty
> > than other synchronization option.   For a one-time effort like domain
> > creation this is ok, but Xenstore is used repeatedly to access data,
> > and therefore performance could potentially be enhanced.
>
> That presentation giving figures comparing pthread_mutex_lock with other
> primitives is useless. It doesn't say what OS / version it was tested on,
> or what those figures are measuring. Linux NPTL (2.6.x) threading has 
> radically
> different (better) pthread_mutex performance characteristics that the older
> LinuxThreads impl (2.4.x) for example, and that's ignoring any other non-Linux
> OS' impl of pthreads. The performance characteristics of a contended mutex 
> lock,
> vs an uncontended lock are also completely different & not considered in those
> figures.
>

Contended locks?   I will looked further into these, thanks.

> Finally there's no performance profile data to suggest that mutex locking
> is even remotely relevant to xenstore performance. There is however data to
> show that the huge amount of I/O xenstored does hurts performance.
>

And so, is there any particular reasons for Xenstored's slow
performance?   Any area needs improvement?

I looked into Xenstored's implementation, and found that it is using
TDB (trivial database, which is also used by SAMBA) as its backbone.
And inside the tdb.c are a lot of locking statements.   What is TDB?
Then I read this article:

http://www.coda.cs.cmu.edu/maillists/codadev/codadev-2003/0202.html

(paying attention to what he said about Dan Bernstein's CDB) and to
refer to what you said - Xenstored is single threaded, so we have a
"single reader/single writer situation" here, and so is a database
structure like tdb really needed?

What I think is we need to redesign these stuff, based on:

    * identifying the characteristic the relative frequency of
read/write access.
    * identifying concurrent readers, and writer - its different model
    * does databases need to be shareable across heterogeneous systems
by a simple file copy across the network like SAMBA?
    * Can't use thread libraries as they conflict with LWP.
    * identifying the minimal amount of mapping operation needed, and
possibly its corresponding hashing structures.
    * and finally, to come up with the simplest design that meet all
the requirements.

Can Dan's CDB be a possible alternative candidate for our database
design?   Please enlighten me :-).

> By all means consider how to improve the performance of xenstored, but do
> so based on *measured* facts about where the current problems are, rather
> than bullet points in a presentation unrelated to Xen.
>

Noted, thanks :-).

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