Reviewer: A reader from NJ, USA
Tom,
I reviewed your book (Expert One-on-One Oracle and Oracle Perf. By design, Cary
Millsap's Optimizing Oracle Performance. Based on these, I have come up with a
little logic of how the Oracle kernel's latch acquisition algorithm will look
like at a very high level. Please confirm if my understanding is correct. The
code snippet is shown below :
Code snippet for latch that sorround an Oracle kernel code
==========================================================
if get_latch(latch_name,Mode) {
/*
.....
.....
Oracle kernel code associated for the latch
.....
.....
*/
release (latch_name)
}
Latch acquisition algorithm
===========================
Boolean get_latch (char *latch_name, char Mode) {
Latch_Acquired := 0;
If (latch for 'latch_name' available) {
Latch_Acquired := 1; /* Mark latch as acquired */
}
If (Latch_Acquired) {
If (Mode = 'I') {
Increment Gets count for Immediate mode
}
else {
Increment Gets count for Willing-to-Wait mode
}
}
else {
If (Mode = 'W') {
Increment MISSES count for Willing To Wait mode
/*
The while loop below consumes CPU time as the process consumes
CPU doing nothing but
spiining for the latch
*/
While (NOT Latch_Acquired) {
If ( Request_Count++ <= LATCH_SPIN_COUNT) {
get_latch (latch_name,Mode);
}
sleep (x); /* This will post a Latch Free WAIT event and
causes */
elapsed time exceed CPU time */
Request_Count = 0;
}
}
else {
Increment MISSES count for Immediate mode
}
}
return (Latch_Acquired);
}
Please confirm if my understanding is correct.
Followup:
funny how much indentation matters ;) I never could read the C code that used
that (very common) style of {}, always had to pretty print it...
anyway, I think the spin loop you have is a bit off, but the gist is there, not
going to nit-pick too much, this is how I might psuedo code that part:
If (Mode = 'W')
{
Increment MISSES count for Willing To Wait mode
/*
The while loop below consumes CPU time as the process consumes
CPU doing nothing but spining for the latch
*/
While (NOT Latch_Acquired)
{
for( request_count = 0;
request_count <= spin_count && !latch_acquired;
request_count++ )
{
try to grab the latch, recursion would be logically wrong...
}
if !Latch_Acquired
{
sleep (x); /* This will post a Latch Free WAIT event
and causes elapsed time exceed CPU time,
note that an overburdened CPU will do the
same in a spin loop (ela > cpu) as we get
pre-empted */
increment sleeps
}
}
}
GOTO a page to Bookmark Review | Bottom | Top
Clarification June 23, 2004
Reviewer: A reader from NJ, USA
Tom,
In the above feedback, you mentioned that recursion would be logically wrong.
1. Can you please eloborate on this please
2. Also, when the process is pre-empted because of busy CPU, it will not show as
WAIT line but will be represented by "Time spent not using the CPU" (which per
Cary Millsap's response time analysis would be counted as N ==> time spent not
utilizing the CPU) and will not appear in any of the wait interfaces since the
wait interfaces do not show the time waiting for CPU.
Is my understanding of 2 correct?
As always, thanks for your very clear explanation
Followup:
1) the recursion would go through all of the checks again and as latch acquired
is a local variable, it would be an infinite loop
2) correct it will not be wait time, it will be unacouunted time. elapsed time
will show it, you won't be able to look at the waits and see what it was.
My point was you stated:
This will post a Latch Free WAIT event and
causes elapsed time exceed CPU time
well, spinning can also cause "elapsed time exceed cpu time" if we get bumped
off. no wait can be recorded -- but ela will go up while CPU does not.
GOTO a page to Bookmark Review | Bottom | Top
Clarification June 23, 2004
Reviewer: A reader from NJ, USA
Tom,
In the above feedback, you mentioned that recursion would be logically wrong.
1. Can you please eloborate on this please
2. Also, when the process is pre-empted because of busy CPU, it will not show as
WAIT line but will be represented by "Time spent not using the CPU" (which per
Cary Millsap's response time analysis would be counted as N ==> time spent not
utilizing the CPU) and will not appear in any of the wait interfaces since the
wait interfaces do not show the time waiting for CPU.
Is my understanding of 2 correct?
As always, thanks for your very clear explanation
[@more@]
Tom,
I reviewed your book (Expert One-on-One Oracle and Oracle Perf. By design, Cary
Millsap's Optimizing Oracle Performance. Based on these, I have come up with a
little logic of how the Oracle kernel's latch acquisition algorithm will look
like at a very high level. Please confirm if my understanding is correct. The
code snippet is shown below :
Code snippet for latch that sorround an Oracle kernel code
==========================================================
if get_latch(latch_name,Mode) {
/*
.....
.....
Oracle kernel code associated for the latch
.....
.....
*/
release (latch_name)
}
Latch acquisition algorithm
===========================
Boolean get_latch (char *latch_name, char Mode) {
Latch_Acquired := 0;
If (latch for 'latch_name' available) {
Latch_Acquired := 1; /* Mark latch as acquired */
}
If (Latch_Acquired) {
If (Mode = 'I') {
Increment Gets count for Immediate mode
}
else {
Increment Gets count for Willing-to-Wait mode
}
}
else {
If (Mode = 'W') {
Increment MISSES count for Willing To Wait mode
/*
The while loop below consumes CPU time as the process consumes
CPU doing nothing but
spiining for the latch
*/
While (NOT Latch_Acquired) {
If ( Request_Count++ <= LATCH_SPIN_COUNT) {
get_latch (latch_name,Mode);
}
sleep (x); /* This will post a Latch Free WAIT event and
causes */
elapsed time exceed CPU time */
Request_Count = 0;
}
}
else {
Increment MISSES count for Immediate mode
}
}
return (Latch_Acquired);
}
Please confirm if my understanding is correct.
Followup:
funny how much indentation matters ;) I never could read the C code that used
that (very common) style of {}, always had to pretty print it...
anyway, I think the spin loop you have is a bit off, but the gist is there, not
going to nit-pick too much, this is how I might psuedo code that part:
If (Mode = 'W')
{
Increment MISSES count for Willing To Wait mode
/*
The while loop below consumes CPU time as the process consumes
CPU doing nothing but spining for the latch
*/
While (NOT Latch_Acquired)
{
for( request_count = 0;
request_count <= spin_count && !latch_acquired;
request_count++ )
{
try to grab the latch, recursion would be logically wrong...
}
if !Latch_Acquired
{
sleep (x); /* This will post a Latch Free WAIT event
and causes elapsed time exceed CPU time,
note that an overburdened CPU will do the
same in a spin loop (ela > cpu) as we get
pre-empted */
increment sleeps
}
}
}
GOTO a page to Bookmark Review | Bottom | Top
Clarification June 23, 2004
Reviewer: A reader from NJ, USA
Tom,
In the above feedback, you mentioned that recursion would be logically wrong.
1. Can you please eloborate on this please
2. Also, when the process is pre-empted because of busy CPU, it will not show as
WAIT line but will be represented by "Time spent not using the CPU" (which per
Cary Millsap's response time analysis would be counted as N ==> time spent not
utilizing the CPU) and will not appear in any of the wait interfaces since the
wait interfaces do not show the time waiting for CPU.
Is my understanding of 2 correct?
As always, thanks for your very clear explanation
Followup:
1) the recursion would go through all of the checks again and as latch acquired
is a local variable, it would be an infinite loop
2) correct it will not be wait time, it will be unacouunted time. elapsed time
will show it, you won't be able to look at the waits and see what it was.
My point was you stated:
This will post a Latch Free WAIT event and
causes elapsed time exceed CPU time
well, spinning can also cause "elapsed time exceed cpu time" if we get bumped
off. no wait can be recorded -- but ela will go up while CPU does not.
GOTO a page to Bookmark Review | Bottom | Top
Clarification June 23, 2004
Reviewer: A reader from NJ, USA
Tom,
In the above feedback, you mentioned that recursion would be logically wrong.
1. Can you please eloborate on this please
2. Also, when the process is pre-empted because of busy CPU, it will not show as
WAIT line but will be represented by "Time spent not using the CPU" (which per
Cary Millsap's response time analysis would be counted as N ==> time spent not
utilizing the CPU) and will not appear in any of the wait interfaces since the
wait interfaces do not show the time waiting for CPU.
Is my understanding of 2 correct?
As always, thanks for your very clear explanation
[@more@]
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/94317/viewspace-794196/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/94317/viewspace-794196/