[quagga-dev 7444] Re: (no subject)

Stephen Hemminger shemminger at vyatta.com
Mon Nov 30 22:44:32 GMT 2009


On Mon, 30 Nov 2009 23:35:12 +0100
Joakim Tjernlund <joakim.tjernlund at transmode.se> wrote:

> Stephen Hemminger <shemminger at vyatta.com> wrote on 30/11/2009 20:43:51:
> >
> > On Mon, 30 Nov 2009 19:22:09 +0100
> > Joakim Tjernlund <joakim.tjernlund at transmode.se> wrote:
> >
> > > >
> > > > On 30/11/2009 17:21, Joakim Tjernlund wrote:
> > > > > linux 2.4 is still in use today because it is much smaller.
> > > >
> > > > Does the sort of glibc that you would use on a linux 2.4 support pthreads?
> > >
> > > Yes, but not NPTL
> > >
> > > >
> > > > let me rephrase: does it support pthreads in a way which is bug-fix
> > > > compatible with current versions of glibc or other libcs which are in use
> > > > on more modern versions of linux?
> > > >
> > > > As another important issue to add to Greg's questions: how inter-compatible
> > > > are the various pthread implementations used by the various operating
> > > > systems that quagga supports?
> > >
> > > No idea, but as far as MONOTONIC_CLOCK goes, one should use times(2) when it
> > > is missing.
> > >
> > > Threads is different issue, I don't think anyone wants to use pthreads on older
> > > linux so no need to try. Just make sure the current "threads" still works after
> > > you have added NPTL support.
> > >
> >
> > Unfortunately, pthread mutex and locking primitives are slow. That is why almost
> > all the databases end up rolling their own. Part of the problem is the glibc clash
> > between being portable and being fast.
> >
> > What is the proposed design for using threads? I am concerned that if it just changes
> > the bottleneck from being a single thread, to having a single lock there will be
> > little performance gain.
> 
> Yes, I am not convinced either. What might work though is to make each daemon
> a thread(zebra, bgp, ospf etc.). However, I do think there is much to do to
> better the performance within the current framework.

Processes are actually faster than threads because they don't share state!
The only reason threads help is when the shared state is helpful. That is why fast web
servers use processes not threads. Now with Quagga, the RIB could be shared between routing
daemons, but the performance bottleneck in routing daemons is updates and these occur
from a single source (usually). Paul was doing some work to fork for some cases where
there was read-only thread (like vtysh dump).



More information about the Quagga-dev mailing list