Gavin Scott writes:

>Chip ponders:
>...
>> The fine folks at HP, upon dialin' in, pronounced that the machine was
>> registering "extreme" amounts of CM-switching.  ?que?!
>
>First make *sure* that they are talking about switches *to* CM (which are
>"bad") as opposed to switches *from* CM (to NM) which are not bad.  Sort of
>like bad cholesterol versus good cholesterol.  You want he total number to
>be as low as possible, but one kind will kill you whereas the other kind
>isn't really bad and may actually be good for you (switching to NM means
>that once there things will run faster than in CM, so switching might be
>better than not switching).

The cholesterol analogy is kind of misleading in this case. Ideally,
there will be *no* switches to NM, and very little time spent in CM.
Having a lot of switches to NM (what Gavin calls the "good" kind) means
that there is code running in CM. If the CM code is doing a lot of work,
that means a performance penalty is being paid for some code that should
be moved to NM. But if the CM program is doing most of the work itself,
the number of CM->NM switches will be fairly low. You need to look at the
"% CM" number to determine whether this is the case.

But having a large number of CM->NM switches isn't good, either. As an
example, look at FCOPY. FCOPY, when doing a plain file copy, will be
doing huge numbers of switches from CM to NM. Gavin says that this is not
generally "bad", but it really is: when the system is switching, it isn't
working. FCOPY is an extreme case, because virtually all its CPU time
will be spent doing switches. The same will be the case of any CM program
that's in a tight loop calling file system (and some other) intrinsics.
In this case, the "% CM" number will be low (FCOPY isn't doing anything
itself; it's just calling the file system), but switches will be very
high.

But just to re-emphasize:

>Switch rates should scale linearly with system activity, and should be
>completely unrelated to any non-linear performance degredation, or any
>limits you might be hitting.

This is correct; the large number of switches in this case is likely to
be just an indicator of system activity rather than the cause of the
problem. On the other hand, the program doing the switching *may* be the
cause of the problem, so the analysis will provide useful data.

Incidentally:
>[Chip:]
>> Well, all of our business applications are compiled into NMPRGs so I went
>> looking elsewhere.

If the switches are Gavin's "bad" kind (NM->CM), the cause could still be
your business applications if they're calling intrinsics for certain
system services which are still implemented in CM. The high switch rate,
if NM->CM, and the fact that you also are getting "Out of DST space"
messages, suggests that you might be using the old mailbox-style
interprocess communication intrinsics (MAIL/SENDMAIL/RECEIVEMAIL). This
is still implemented in CM (or was, when last I checked), and uses extra
data segments to store messages.

-- Bruce



--------------------------------------------------------------------------
Bruce Toback    Tel: (602) 996-8601| My candle burns at both ends;
OPT, Inc.            (800) 858-4507| It will not last the night;
11801 N. Tatum Blvd. Ste. 142      | But ah, my foes, and oh, my friends -
Phoenix AZ 85028                   | It gives a lovely light.
[log in to unmask]                   |     -- Edna St. Vincent Millay