Re: [PATCHES] update i386 spinlock for hyperthreading

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Jan Wieck <JanWieck(at)Yahoo(dot)com>
Cc: Manfred Spraul <manfred(at)colorfullife(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org, markw(at)osdl(dot)org
Subject: Re: [PATCHES] update i386 spinlock for hyperthreading
Date: 2003-12-30 16:48:10
Message-ID: 200312301648.hBUGmAT01243@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers pgsql-patches

Jan Wieck wrote:
> Manfred Spraul wrote:
> > Bruce Momjian wrote:
> >
> >>>Anyone see an attack path here?
> >>>
> >>>
> >>
> >>Should we have one lock per hash bucket rather than one for the entire
> >>hash?
> >>
> >>
> > That's the simple part. The problem is the aging strategy: we need a
> > strategy that doesn't rely on a global list that's updated after every
> > lookup. If I understand the ARC code correctly, there is a
> > STRAT_MRU_INSERT(cdb, STRAT_LIST_T2) that happen in every lookup.
>
> Moving the Cache Directory Block (cdb) on a hit to the MRU position of
> the appropriate queue "is the bookkeeping" of this strategy. The whole
> algorithm is based on it, and I don't see yet how to avoid that without
> opening a huge can of worms that look like deadlocks. But I'll think
> about it for a while.

If we can't eliminate the global lock, and we reduce its duration?

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Jan Wieck 2003-12-30 16:55:43 Re: [PATCHES] update i386 spinlock for hyperthreading
Previous Message Paul Ganainm 2003-12-30 16:45:47 Re: Groff and Weinberg SQL Complete Reference - Sample

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2003-12-30 16:51:41 Re: select() for small sleep
Previous Message Paul Ganainm 2003-12-30 16:42:39 Re: Is my MySQL Gaining ?

Browse pgsql-patches by date

  From Date Subject
Next Message Tom Lane 2003-12-30 16:51:41 Re: select() for small sleep
Previous Message Andrew Dunstan 2003-12-30 15:37:36 select() for small sleep