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? -adrianReceived on Thu Jul 25 2013 - 14:11:39 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:39 UTC