Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 13 Nov 2006 04:20:09 +0000
From:      Chris <chrcoluk@gmail.com>
To:        "David Xu" <davidxu@freebsd.org>
Cc:        freebsd-current@freebsd.org
Subject:   Re: libpthread vs libthr.
Message-ID:  <3aaaa3a0611122020n461719nfad2adf378498f5a@mail.gmail.com>
In-Reply-To: <200611130707.10220.davidxu@freebsd.org>
References:  <20061110151247.GA64530@zone3000.net> <3aaaa3a0611111503m319808cu7e1f710970350044@mail.gmail.com> <200611130707.10220.davidxu@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On 12/11/06, David Xu <davidxu@freebsd.org> wrote:
> On Sunday 12 November 2006 07:03, Chris wrote:
> > On 10/11/06, Nikolay Pavlov <quetzal@zone3000.net> wrote:
> > > Hi. In this post i am not trying to raise a discussion about teoretical
> > > advantages of some special threading model, but still i would like to
> > > figure out why libthr in it current state is not our default posix
> > > thread library and could it be so in time of 7-STABLE?
> > >
> > > As a user and administrator of FreeBSD i want to mention some benefits
> > > of libthr:
> > >
> > > 1. It's simpler.
> > > 2. It's stable and has been used by many of us for a long time.
> > > 3. It proved to be very productive on real world applications.
> > > 4. It has active talented developers.
> > > 5. If it was a default library it would couse a incrase of users
> > > feedback which would lead to futher improvement of it's code by the time
> > > 7 becomes a stable branch.
> > >
> > > And some flaws of libpthread:
> > >
> > > 1. It's more difficult.
> > > 2. It's slow in compare of libthr.
> > > 3. The last, but the worst. IMHO the position under which libpthread is
> > > the library by default is the source of a bad myth that threading model
> > > in FreeBSD sucks and threading applications is slow. If 7.0 had libthr
> > > as a default posix threads library we could brake that belief.
> > >
> > > This point of view may seem one-sided that is why someone with good
> > > knowledge of the current state of code could tell other pros and cons
> > > of both libraries.
> > >
> > > Another interesting question is which of the libraries will better work
> > > with multikernel and multiprocessor systems which will be very popular
> > > by the time 7.0 branch launches its stable releases.
> > >
> > > --
> > > ======================================================================
> > > - Best regards, Nikolay Pavlov. <<<-----------------------------------
> > > ======================================================================
> >
> > HI I posted in another thread about how my own experiences seem to
> > differ from all these benchmarks, they are based on 3 heavily loaded
> > web/mysql servers.
> >
> > One is freebsd 6.1 dual core cpu (not htt). 2nd is dual xeon freebsd
> > 6.1 and 3rd is another dual xeon freebsd 6.1.
> >
> > All 3 of these machines perform better as well as more stable under
> > higher loads using libpthread process scope.
> >
> > System scope appears to make mysql hog the system and everything slows
> > down except of course mysql.
> >
> > Libthr appears to make mysql very sporadic with some requests fast
> > others with a unexplained 5-10 sec delay including timeouts.
> >
> > Process scope on libpthread gives me the best results not making mysql
> > starve the server of resources and it has a consistent response time
> > of under 2 seconds under hevay loads.
> libthr on FreeBSD 6.1 respects process scope, if your mysql is compiled
> with process scope, it will use it, this is only removed in -CURRENT,
> I don't know why you said that it starved server resource if KSEGRP
> really works as expected.
>
> >
> > I cant explain other then it maybe that test mysql data isnt a proper
> > way to test these threading libraries only real work loads can.
> >
> > Chris
> > _______________________________________________


Interesting libthr can use system or process scope?  as far as I am
aware it was using whatever the default is for libthr.

Chris



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3aaaa3a0611122020n461719nfad2adf378498f5a>