I haven't done much messing with scheduling. It is set at the default ULE for this machine. On Thu, Jul 25, 2013 at 12:11 PM, Adrian Chadd <adrian_at_freebsd.org> wrote: > On 25 July 2013 02:51, Wojciech Puchar <wojtek_at_wojtek.tensor.gdynia.pl> > wrote: > >> improved with a higher kern.hz rating. Unless the future holds an > emu20k2, > >> there will be RAM used from the motherboard. > >> 1. I will need a real-time or a faster kernel- hence the high rate > wanted- > >> because the devices to be built will be used in an active environment: > >> art, > >> music, audio control. > >> 2. Any system with limited memory and a low CPU hertz rate benefits from > >> the higher kern.hz setting. > > > rather opposite. more kern.hz=more interrupts. > > Right. > > More hz == more interrupts and less ability for a CPU-bound process to > chew all the CPU. > > So is it a scheduling issue, where you have multiple CPU bound > userland processes that aren't being fair and consuming all the CPU? > Is it that your device driver(s) aren't interrupting correctly, > relying on the hz tick to make up the slack, etc. > > Is it a busted halt loop, which is being papered over with hz ticks? > > Have you tried -10 on that kit, with the more aggressive clock/timer > code that won't interrupt unless it needs to? Has that changed things? > > > > -adrian >Received on Thu Jul 25 2013 - 18:31:55 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:39 UTC