Date: Wed, 10 Aug 2011 19:43:01 -0300 From: Mario Lobo <lobo@bsd.com.br> To: bf1783@gmail.com Cc: freebsd-questions@freebsd.org Subject: Re: High interrupt rate Message-ID: <201108101943.01874.lobo@bsd.com.br> In-Reply-To: <CAGFTUwN2%2BDk03EZs0UpxqPOuu5JnuxVd0DT2j%2BSCWMkUSU_Cpw@mail.gmail.com> References: <CAGFTUwNPAJOPEzzPsd=4kdyMkQH-y6LrNkeZD11578uPY5eO0g@mail.gmail.com> <201108072028.09658.lobo@bsd.com.br> <CAGFTUwN2%2BDk03EZs0UpxqPOuu5JnuxVd0DT2j%2BSCWMkUSU_Cpw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201108101943.01874.lobo>