Re: Latch spin - OS timeslice

Jonathan Lewis <jonathan_at_jlcomp.demon.co.uk> wrote:
>
>Secondly, as the sleep is coded to 1/100 sec
>minimum, it should arguably be set so that
>'opportunity cost' of that lost time is related
>to the CPU cost of spinning.
>
>On a CPU at 200MHz, a sleep is typically
>equivalent to 'not doing' 200 logical I/Os.
>On a CPU at 500MHz, a sleep is typically
>equivalent to 'not doing' 500 logical I/Os.
>Therefore you should be prepared to waste
>a little more CPU spinning in order to avoid
>missing the opportunity for doing so much
>extra work.

This is the best-case. On a busy system it may be far worse, a sleep means that process is descheduled from the CPU and can do no useful work until it gets another slot.

A typical UNIX system has a scheduling quantum of 1/100 seconds, so a process that does no I/O or system calls can stay on a CPU for up to 10ms. Hm... Just speculation here but, that may be another reason to avoid very large values for _spin_count, typically a process which exhausts its whole quantum on the CPU will get a reduced priority for later scheduling, so you may end up starving your shadow processes of CPU resource by trying to make them overly aggressive on latch gets.

IIRC, the first sleep of a latch get is a "zero second" sleep, which simply deschedules that process, and makes it immediately available for rerunning. Later latch sleeps are normal waits.

-- 
Andrew Mobbs - http://www.chiark.greenend.org.uk/~andrewm/