High interrupt rate

[Mario Lobo]

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
> conditions.
> 
> 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:
> 
> kern.timecounter.smp_tsc="1"
> 
> 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.
> 
> b.

b.;

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.

-- 
Mario Lobo
http://www.mallavoodoo.com.br
FreeBSD since 2.2.8 [not Pro-Audio.... YET!!] (99% winblows FREE)