RE: spin_count and cpu usage

>>>Well, thanks to faster CPUs the time to try to get a latch
(spin) has reduced, but also the time to release the latch (to complete the work that requires latch protection) has gone down as well.

...every installment on this thread so far presumes a simple test and set or other such simple spin-to-get implementations of kslget. Depending on the port, there are more sophisticated lightweight locks being used by Oracle for latches such as Sun's adaptive mutexes and assemply that is much better than those wild loops of test and set such as IBMs famed "lorks and storks" (lwarx/stcwx).
Others ports didn't even implement software locks throughout such as the HP-UX port to the V Series, where the most critcal latches at the
time (scn, redo allocation, shared pool,etc ) were implemented with hardware
locks. Although I was suspicious at the time that that particular port was only used for TPC-C benchmarks. The fact that the software being used for an audited TPC-C is itself not audited is a whole different story :-)

I would say that considering how "flat" memory is on most of todays systems combined with what little port-level details there are about ksl, it probably is not wise to start setting the spin_count values. Besides, if you have "real" latch contention, you probably can't spin enough no matter what you do...you may be on a port that routinely has latch holders getting bumped off CPU...there is no protection for that in the Linux ports for certain. What value do you want to spin for if the holder is in a runable state and might not get back on CPU for another 10 millisecond? No sense spinning at all in that case really...

--
http://www.freelists.org/webpage/oracle-l