AW: AW: Re[4]: [HACKERS] Allowing WAL fsync to be done via O_SYNC

2001-03-19 Thread Zeugswetter Andreas SB


  It's great as long as you never block, but it sucks for making things
  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.
 
 HPUX has usleep, but the man page says
 
  The usleep() function is included for its historical usage. The
  setitimer() function is preferred over this function.

I doubt that setitimer has microsecond precision on HPUX.

 In any case, I would expect that all these functions offer accuracy
 no better than the scheduler's regular clock cycle (~ 100Hz) on most
 kernels.

Not on AIX, and I don't beleive that for the majority of other UNIX platforms eighter. 
I do however suspect, that some implementations need a busy loop, which would, 
if at all, only be acceptable on an SMP system.

Andreas

---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])



AW: Re[4]: [HACKERS] Allowing WAL fsync to be done via O_SYNC

2001-03-16 Thread Zeugswetter Andreas SB


  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@s0188000zeu:/usr/postgres time ustest # with 100 us
real0m10.95s
user0m0.40s
sys 0m0.74s

postgres@s0188000zeu:/usr/postgres time ustest # with 10 us
real0m18.62s
user0m1.37s
sys 0m5.73s

Andreas

PS: sorry off for weekend now :-) Current looks good on AIX.


 ustest.c


---(end of broadcast)---
TIP 6: Have you searched our list archives?

http://www.postgresql.org/search.mpl



Re: AW: Re[4]: [HACKERS] Allowing WAL fsync to be done via O_SYNC

2001-03-16 Thread Tom Lane

Zeugswetter Andreas SB  [EMAIL PROTECTED] writes:
 It's great as long as you never block, but it sucks for making things
 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.

HPUX has usleep, but the man page says

 The usleep() function is included for its historical usage. The
 setitimer() function is preferred over this function.

In any case, I would expect that all these functions offer accuracy
no better than the scheduler's regular clock cycle (~ 100Hz) on most
kernels.

regards, tom lane

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]