> > Hi hackers,
> > I have old patches for version 6.2.1p6 which fix some problems and add
> > new features. Here is a short description of each patch file:
> > spin-lock.patch
> > I'm not sure if this is really useful, but it seems stupid to have
> > a backend wasting cpu cycles in a busy loop while the process which
> > should release the lock is waiting for the cpu. So I added a call
> > to process_yield() if the spin lock can't obtained.
> > This has been implemented and tested only on Linux. I don't know if
> > other OS have process_yield(). If someone can check please do it.
The generic way to do this is
select( NULL_FDSET, NULL_FDSET, NULL_FDSET, &delaytime, NULL);
Delay time may be 0, but a random value between 0 and say 30 msec seems
to be optimal. Hard busy wait spinlocks cause huge performance problems with
heavily loaded systems and lots of postgres backends. Basically one backend
ends up with the lock and gets scheduled out holding it, every else queues
up busywaiting behind this one. But the backend holding the lock cannot
release it until all the other backeds waiting on the lock exhaust a full
timeslice busywaiting. Get 20 of these guys going (like on a busy website) and
the system pretty much stops doing any work at all.
I say we should get this in as soon as we can.
> > --
> > Massimo Dal Zotto
> Massimo, now that 6.3 is released, any chance of getting these patches
> against the 6.3 source code?
> Bruce Momjian | 830 Blythe Avenue
> maillist(at)candle(dot)pha(dot)pa(dot)us | Drexel Hill, Pennsylvania 19026
David Gould dg(at)illustra(dot)com 510.628.3783 or 510.305.9468
Informix Software (No, really) 300 Lakeside Drive Oakland, CA 94612
- I realize now that irony has no place in business communications.
In response to
pgsql-hackers by date
|Next:||From: David Gould||Date: 1998-03-16 23:38:10|
|Subject: Re: [HACKERS] spin locks|
|Previous:||From: Jackson, DeJuan||Date: 1998-03-16 21:51:46|
|Subject: RE: [HACKERS] AUTOINDEXING AND HOROLOGY REGRESSION ERROR ON PGSQL 6.3, LINUX-ELF i686|