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