The correct answers depend on your perspective. The application users don't care how the time is categorized. They just know performance is unacceptable and it's impacting their ability to get their work done. Operating system administrators see only CPU busyness (that is, utilization) and the CPU run queue. So their understanding-or better said, their ability to clearly see the picture-is limited.

From a DBA perspective, understanding how Oracle response time relates to latch contention time is paramount. Keep in mind that it is very convenient for DBAs when CPU time is classified as service time. Therefore, when an Oracle process is spinning on a latch, it makes sense to record the spin time as CPU time. And, in fact, Oracle does do this. As spinning increases, you will observe Oracle processes consume more CPU time, and therefore also notice the CPU subsystem becomes increasingly busy. Relating back to the situation with the room full of people waving their arms and yelling "Give me the latch," consider all that activity takes energy. In the real Oracle world, this energy is CPU consumption.

So, we have the application users waiting for their application to respond and Oracle DBAs waiting for the Oracle process to acquire the latch, but I have made no mention of Oracle wait event time. I stated spinning on a latch consumes CPU time, but have made no mention of what constitutes the Oracle wait event latch free. If Oracle considered and recorded CPU spin time as wait time, yet it also recorded CPU spin time as service time, then Oracle would double-count the spin time. In other words, 20 ms spinning would result in a response time of 40 ms: 20 ms for CPU consumption while spinning and 20 ms for latch wait time.