From: | Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at> |
---|---|
To: | "'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alfred Perlstein <bright(at)wintelcom(dot)net> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | AW: Re[4]: Allowing WAL fsync to be done via O_SYNC |
Date: | 2001-03-16 17:14:06 |
Message-ID: | 11C1E6749A55D411A9670001FA687963368251@sdexcsrv1.f000.d0188.sd.spardat.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> >> definitely need before considering this is to replace the existing
> >> spinlock mechanism with something more efficient.
>
> > What sort of problems are you seeing with the spinlock code?
>
> It's great as long as you never block, but it sucks for making things
I like optimistic approaches :-)
> wait, because the wait interval will be some multiple of 10 msec rather
> than just the time till the lock comes free.
On the AIX platform usleep (3) is able to really sleep microseconds without
busying the cpu when called for more than approx. 100 us (the longer the interval,
the less busy the cpu gets) .
Would this not be ideal for spin_lock, or is usleep not very common ?
Linux sais it is in the BSD 4.3 standard.
postgres(at)s0188000zeu:/usr/postgres> time ustest # with 100 us
real 0m10.95s
user 0m0.40s
sys 0m0.74s
postgres(at)s0188000zeu:/usr/postgres> time ustest # with 10 us
real 0m18.62s
user 0m1.37s
sys 0m5.73s
Andreas
PS: sorry off for weekend now :-) Current looks good on AIX.
Attachment | Content-Type | Size |
---|---|---|
ustest.c | application/octet-stream | 68 bytes |
From | Date | Subject | |
---|---|---|---|
Next Message | Zeugswetter Andreas SB | 2001-03-16 17:14:29 | AW: Allowing WAL fsync to be done via O_SYNC |
Previous Message | Mikheev, Vadim | 2001-03-16 17:10:43 | RE: Re[4]: Allowing WAL fsync to be done via O_SYNC |