Re: Latch spin - OS timeslice

 CPU0 is the master CPU and you will notice a slight skew on it - possibly higher counts than the others in a spin case.

Double check your perception on lockstat. The command that follows (now this is from memory here) is like a sleep command. Lockstat when run as root pulls info directly from the kernel. You will see the mutex spin events displayed and from there depending on your sample time - e.g. sleep 10. You divide that number by 10 and that should correspond to the SMTX column/second within mpstat.

Try the following. Construct an infinite loop in a shell script - e.g. while (1) do...

truss this process as it runs. Note that the system time should be a lot higher than the user time due to the contention caused. To lock something at that low a level (and I'm no programmer) it has to be done via a system call, not from the user level. Therefore if there is a spin, the wait on the spin should be system time as the call was a system call. The good thing about unix is that there are multiple tools and you can usually cross reference them against each other.

If I am incorrect I humbly stand corrected......

Regards,
Kyle
www.gadgets.co.nz

"Yong Huang" <yong321_at_yahoo.com> wrote in message news:b3cb12d6.0203280948.5e05b091_at_posting.google.com...
> Hi, Kyle,
>
> Why do you think CPU0 should take more load? We're all using symmetric
> multi-processor machines.
>
> I've never seen srw (spins on reader-writer locks) showing anything
> other than 0. May be a bug in mpstat. Why do you expect sys time to be
> higher? I thought spins consumed user time, not sys time.
> Cross-processor calls (xcal), among other things, drive up sys time.
>
> lockstat doens't allow you probe a process other than the command
> following lockstat. Usage is lockstat [options] command. Otherwise it
> would be the ideal tool. I don't know why they wrote this program this
> way. Unfortuntely the API for lockstat(7D) is not published.
>
> Somebody in Oracle should know how long 1 latch get spin takes because
> the default _spin_count 2000 can't be an arbitrary number.
> Regards,
>
> Yong Huang
> yong321_at_yahoo.com
>
> > I'd be interested in looking at the mpstat output for all processors.
You
> > should notice a higher smtx count for proc 0 being the master may be
higher.
> > But, a count of 100 is not a problem from what I have seen.
> >
> > Is the sys time from vmstat greatly higher than the user time?
> >
> > What does the mpstat column srw indicate. Is it a lot higher than the
smtx
> > col?
> >
> > Unfortunately I am not near a sun machine as I have been working on NT
for a
> > bit now, but from memory, the lockstat command "man lockstat" will dump
all
> > lock contention for you.
Received on Thu Mar 28 2002 - 16:35:24 CST