Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 25 Jul 2013 16:31:53 -0400
From:      Super Bisquit <superbisquit@gmail.com>
To:        Adrian Chadd <adrian@freebsd.org>
Cc:        Wojciech Puchar <wojtek@wojtek.tensor.gdynia.pl>, freebsd-current <freebsd-current@freebsd.org>, FreeBSD Hackers <freebsd-hackers@freebsd.org>, FreeBSD PowerPC ML <freebsd-ppc@freebsd.org>
Subject:   Re: Kern.hz= +1 hertz at anything 2500 and above.
Message-ID:  <CA%2BWntOuasi-OLCkOewzQHS2L_MQXkNu5z2z4fcscpKST5c3=Vw@mail.gmail.com>
In-Reply-To: <CAJ-VmokKMwuo8dRRXGzZttaoay%2BJk_hfk_ESVdZX4m55CzXVCg@mail.gmail.com>
References:  <CA%2BWntOvcN%2BLEog5_W6aQUT%2BZw_5ZgEkdYEcR8QTW3zZSUOuypA@mail.gmail.com> <CAJ-VmonFMXg_PcG=daU7Vk2r89epr6PpMHGdbnMLyFY=FgvNYQ@mail.gmail.com> <CA%2BWntOspTSm3OM23KrY5vzDasuGVOU0HSK7BOuLaxgbvPVB8=g@mail.gmail.com> <alpine.BSF.2.00.1307251150400.12856@wojtek.tensor.gdynia.pl> <CAJ-VmokKMwuo8dRRXGzZttaoay%2BJk_hfk_ESVdZX4m55CzXVCg@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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@freebsd.org> wrote:

> On 25 July 2013 02:51, Wojciech Puchar <wojtek@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
>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CA%2BWntOuasi-OLCkOewzQHS2L_MQXkNu5z2z4fcscpKST5c3=Vw>