Re: Spinlock performance improvement proposal

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Alex Pilosov <alex(at)pilosoft(dot)com>
Cc: "D(dot) Hageman" <dhageman(at)dracken(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Spinlock performance improvement proposal
Date: 2001-09-28 19:07:12
Message-ID: 200109281907.f8SJ7Cg12343@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


FYI, I have added a number of these emails to the 'thread' TODO.detail list.

> On Wed, 26 Sep 2001, D. Hageman wrote:
>
> > > > Save for the fact that the kernel can switch between threads faster then
> > > > it can switch processes considering threads share the same address space,
> > > > stack, code, etc. If need be sharing the data between threads is much
> > > > easier then sharing between processes.
> > >
> > > When using a kernel threading model, it's not obvious to me that the
> > > kernel will switch between threads much faster than it will switch
> > > between processes. As far as I can see, the only potential savings is
> > > not reloading the pointers to the page tables. That is not nothing,
> > > but it is also
> <major snippage>
> > > > I can't comment on the "isolate data" line. I am still trying to figure
> > > > that one out.
> > >
> > > Sometimes you need data which is specific to a particular thread.
> >
> > When you need data that is specific to a thread you use a TSD (Thread
> > Specific Data).
> Which Linux does not support with a vengeance, to my knowledge.
>
> As a matter of fact, quote from Linus on the matter was something like
> "Solution to slow process switching is fast process switching, not another
> kernel abstraction [referring to threads and TSD]". TSDs make
> implementation of thread switching complex, and fork() complex.
>
> The question about threads boils down to: Is there far more data that is
> shared than unshared? If yes, threads are better, if not, you'll be
> abusing TSD and slowing things down.
>
> I believe right now, postgresql' model of sharing only things that need to
> be shared is pretty damn good. The only slight problem is overhead of
> forking another backend, but its still _fast_.
>
> IMHO, threads would not bring large improvement to postgresql.
>
> Actually, if I remember, there was someone who ported postgresql (I think
> it was 6.5) to be multithreaded with major pain, because the requirement
> was to integrate with CORBA. I believe that person posted some benchmarks
> which were essentially identical to non-threaded postgres...
>
> -alex
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2001-09-28 19:21:24 Re: Spinlock performance improvement proposal
Previous Message Bruce Momjian 2001-09-28 18:52:59 Re: Spinlock performance improvement proposal