>>> I'm seeing something jump into the processor for almost exactly a
>>> millisecond every 7.32 seconds. It does happen in single-user mode,
>>> but I don't recall seeing this in earlier tests. Clearly I turned some-
>>> thing on I shouldn't have or turned something off that someone still
>>> wants to see. Killing vold got rid of a 3 mSec chirp every 3 seconds
>>> but now this one crops up. Urg... ;-)
>> How are you detecting this activity?
> A real-time task sends a timestamped message to another task at a
> periodic rate. The receiving task timestamps the receipt of the message
> and keeps stats. It looks really good except the these little chirps that
> are showing up...
This *may* be bug 4912731 in which the memscrub thread can overstay
it's welcome on cpu for a moment too long, and can therefore interfere
with realtime dispatch if realtime has not been isolated to it's own
CPU set. This affects both sparc and x86 Solaris (although the history
to each is different). A workaround is to reduce the memscrub span
but let's verify the cause first:
You can cause the memscrub to exit on a booted x86 system with
# echo "disable_memscrub/W1" | mdb -kw
Note that you can't start it again. You can make the thread never
start by setting that in /etc/system (of course you then have
nothing keeping memory fresh).
Try that and see if the blip disappears.
Alternatively, here's how the memscrub wakeup interval is computed
Obtain values for the following with the commands shown:
memscrub_period_sec # echo "memscrub_period_sec/U" | mdb -k
memscrub_span_pages # echo "memscrub_span_pages/U" | mdb -k
memscrub_phys_pages # echo "memscrub_phys_pages/U" | mdb -k
The first two have default values, the last depends on your installed
physical memory size. Now:
for memscrub_phys_pages <= memscrub_span_pages, use memscrub_period_sec
otherwise use memscrub_phys_pages/memscrub_span_pages
The result gives the interval in seconds of memscrub wakeups
(provided it isn't falling behind). Is this the magic 7.32s?
>> This sounds like it may be either fsflush or memscrub. fsflush wakes
>> up every 5s by default as far as I remember. memscrub wakes up
>> at odd looking intervals in order to scrub all of physical memory
>> over a 12 hr period. Try disabling the latter (see Sunsolve)
>> temporarily to confirm.
> I'd love to, but I have no SunSolve access. I'm just a lowly
> Solaris x86 user with no service contract. :-(
And you managed to get the owner of the above bug - not bad :-)
Quote:> I am evaluating Solaris for potential use at work, but I need to get
> past some of the learning curve to know what to turn off to prevent
> these chirps, even on a uniprocessor. On a multiprocessor, we'd
> certainly want to minimize the noise, but I can't find any info at all
> on what to turn off (and how). Someone else was kind enough to
> mention disabling vold to get rid of a 3mSec/3Sec chirp, but I
> guess there's lots more...
The vold sounds like a bug, too, if it's interfering with realtime
Realtime on a uniprocessor should work, but relies on all parties
playing the game correctly. The only things of higher priority
than realtime are interrupts, and threads which disable kernel
preemption for short periods (they're not higher priority, but
we can't kick them off cpu until they reenable preemption).
Device interrupts are supposed to be very short and so should
not delay realtime dispatch beyond bounds; but of course if
you have some badly behaved driver it may do otherwise.
Similarly, if someone disables preemption for longer than they
should (as memscrub does) they can interfere.
On a multiprocessor you dedicate cpu resource and shelter that
from device interrupts (not always possible on x86 architecture)
to isolate your realtime processes. Of course to call them
realtime processes, as opposed to merely processes in the RT
scheduling class, they have a number of obligations to fulfill
such as locking their memory in physical memory, not sharing
data disks with others, avoiding lazy linking etc.
>> When you care about other sharing a cpu with you the approach
>> is to set aside processors in a processor set (psrset(1M)) and
>> set all those no-intr (no device interrupts). Now only threads
>> that you launch to that processor set (and their children) run
>> there, and this includes the service kernel threads such as
>> fsflush etc.
> Good info for when I can get a multiprocessor system - thanks.