High interrupt rate
lobo at bsd.com.br
Wed Aug 10 22:43:10 UTC 2011
On Monday 08 August 2011 21:30:41 b. f. wrote:
>> I'll wait for your views on those before disabling polling on the kernel
>> and hz=100.
> It looks like your interrupt rate, while probably higher than needed,
> is not unexpectedly high for your configuration. But you can lower it
> if you want to do so.
> You are using a system before the introduction of the new eventtimer
> code. If you use 9.x, that has the new code and some other
> timer-related improvements, and you are not performing polling, then
> you can achieve a large reduction in the number of timer interrupts
> when the system isn't busy. You can still achieve a reduction on 8.x,
> but the reduction usually won't be as large as on 9.x under similar
> To reduce timer interrupts on an idle system running 8.x or 9.x, if
> you do not need to poll (most systems do not), remove DEVICE_POLLING
> from your kernel, and lower kern.hz to a suitable value -- 100 or 250,
> for example. For many workloads, a lower value is not only adequate,
> but may also be better in some ways.
> Also, you may want to consider using your TSC as the system
> timecounter, because it is usually more efficient to do so. This may
> not work for SMP, because if there are multiple TSCs on your system,
> they may not be synchronized. In 9.x, there is a test for
> synchronization, and the TSCs are preferred to the ACPI-safe timer if
> they satisfy this test and meet some other requirements. In 8.x, the
> user has to tell the system that it is safe to use the TSCs by adding:
> to /boot/loader.conf. If you are not putting your cores into the C3
> state, then you could try setting this via the loader command line,
> booting, and then seeing if the kern.timecounter.tc.TSC.quality is
> positive, kern.timecounter.hardware is TSC, and everything is working
> as expected. If the results are satisfactory, then you could add the
> above entry to /boot/loader.conf. But it would be better to do this
> on 9.x, where there are some added safeguards.
Something really odd happened. After I sent you the data, while waiting for
your reply, I changed Lusca cache to use 64M ram instead of the 256M it had.
It was 1/8th of ram so I just decided to give it less.
Well, I swear to you this was the ONLY thing I did!. Since then, the system
has been running at around 97% idle 98% of the time! During load hours, there
are only short(1s) spikes of 75%ish idle, far from each other. And web
performance is actually a little better! And the overall response of the
system improved. That's why I waited a couple of days to reply so I could
confirm this behavior.
I don't know. Maybe with more ram, lusca was spawning to many threads and thus
loading the CPU but this is just a guess. I will take lusca memory back to 256
for the sake of checking but I want to find out if this new found estability
is there to stay so I'll wait a little longer to do that.
Your suggestions will be kept handy just in case.
Thanks for everything.
FreeBSD since 2.2.8 [not Pro-Audio.... YET!!] (99% winblows FREE)
More information about the freebsd-questions