> I have been thinking some more about the s_lock() delay loop in
> connection with this. We currently have
>
> /*
> * Each time we busy spin we select the next element of this array as the
> * number of microseconds to wait. This accomplishes pseudo random back-off.
> * Values are not critical but 10 milliseconds is a common platform
> * granularity.
> *
> * Total time to cycle through all 20 entries might be about .07 sec,
> * so the given value of S_MAX_BUSY results in timeout after ~70 sec.
> */
> #define S_NSPINCYCLE 20
> #define S_MAX_BUSY 1000 * S_NSPINCYCLE
>
> int s_spincycle[S_NSPINCYCLE] =
> { 0, 0, 0, 0, 10000, 0, 0, 0, 10000, 0,
> 0, 10000, 0, 0, 10000, 0, 10000, 0, 10000, 10000
> };
>
> Having read the select(2) man page more closely, I now realize that
> it is *defined* not to yield the processor when the requested delay
> is zero: it just checks the file ready status and returns immediately.
Actually, a kernel call is something. On kernel call return, process
priorities are checked and the CPU may be yielded to a higher-priority
backend that perhaps just had its I/O completed.
I think the 0 and 10000 are correct. They would be zero ticks and one
tick. You think 5000 and 10000 would be better? I can see that.
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026
