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

["Peter Teoh" <htmldeveloper@xxxxxxxxx>]

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