RE: spin_count and cpu usage
- From: "Kevin Closson" <kevinc@xxxxxxxxxxxxx>
- To: "Oracle-L Freelists" <oracle-l@xxxxxxxxxxxxx>
- Date: Tue, 5 Sep 2006 08:56:02 -0700
>>>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...
--
//www.freelists.org/webpage/oracle-l
Other related posts:
