Re: Kern.hz= +1 hertz at anything 2500 and above.

From: Super Bisquit <superbisquit_at_gmail.com>
Date: Thu, 25 Jul 2013 16:37:22 -0400
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.
>
The G3 had the other scheduler- not ULE- when I built the system.

>
> Is it a busted halt loop, which is being papered over with hz ticks?
>
I wouldn't know. How would I test for this?

>
> Have you tried -10 on that kit, with the more aggressive clock/timer
> code that won't interrupt unless it needs to?

Set the rate to -10 ? I'll try the aggressive clock/timer code if someone
would point me to a tutorial for setting it up. That sounds more like a
solution I like.

> Has that changed things?
>
If I can implement it, it may be the best solution.

>
>
>
> -adrian
>
Received on Thu Jul 25 2013 - 18:37:23 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:39 UTC