On Sat, Sep 15, 2007 at 02:01:12PM +0800, Peter Teoh wrote:
> 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?
The primary problem is the amount of I/O it does per transaction, and then
indirectly, the huge number of transactions XenD makes.
http://lists.xensource.com/archives/html/xen-devel/2006-10/msg00487.html
I repeated those tests against Xen 3.1 a few months back and the characteristics
haven't changed all that much. Running further OProfile tests on a debug build
would confirm this.
> (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:
Since it is not possible to ever actually restart xenstored, the easy answer
is to not use any database on disk at all. Simply keep the entire information
set in RAM. None of the data is keeps per VM needs to persist once the VM
shuts down - all the important state is maintained by XenD which does persist.
Dan.
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules: http://search.cpan.org/~danberr/ -=|
|=- Projects: http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home