Re: Debian on Pine64 H64B?
On Tue, Sep 21, 2021 at 11:36:51AM -0400, Gene Heskett wrote:
> Humph, idea borrowed from the Z-80 of the very late 70's, or possibly
> from the TI 9900's, which had no registers, all in memory and it changed
> context by resetting the index counter to a different address for a new
> set of registers. Same idea, different execution but it worked well.
Well those required the software to ask to change the pointer to memory
for the registers. The hyperthreading just has two sets of registers and
switches between them whenever the other thread stalls (so no delay for
any code to run to do the switch). But since to the OS it looks like 2
CPUs, the fact that the amount of clock cycles each thread gets to execute
varies, makes to a mess if you are trying to do predicable realtime.
I certainly can't imagine a real time system working right with
hyperthreading enabled.
> But it in 3 examples of the Z-80 in about 1981 while I was coding up an
> ATS that looked like a transmitter remote control (different FCC rules)
> only 1 would reliably swap registers when it read an E6 command. I paid
> for two more as the warranty had expired by the time I discovered it, so
> in 5 examples, I actually got two that worked. They were about $35/copy
> at the time. I mistakenly thought it might have been a step up from the
> first micro-controller I used to make a commercial production tool at a
> tv station, an RCA 1802.
>
> That was in 1979-80, and turned out to be so handy they were still using
> it in 1995. Thats a couple eons in tv station control room gear life.
> The RCA Just Worked, the Zilog not so much. I've done several other tv
> production related projects since, never touched a Zilog product again.
> Very bad aftertaste.
>
> Motorola's 6809, now the smarter Hitachi 6309, a cmos workalike until we
> discovered it had more registers than the moto version. A fact that
> hitachi is still contractually enjoined from ever confirming the
> existance of, they had permission to clone it, but never saw the moto
> masks, so they microcoded it, filling up the empty spaces in the 6809
> mapping. So that was my fav small cpu for 30 years.
>
> In any event, it sure screws things up in terms of IRQ latency. The other
> thing we turn off if we can is the SMS stuff, it can throw a several
> millisecond monkey wrench into the gears if software stepping. Not very
> often, but will leave its mark (litteraly) on the part being carved at
> the time. A gear tooth out of position, which since cutting a gear tooth
> is a repetitive operation, means that tooth may be narrower by .001".
>
> Another item that impinges on the arm speed is that the arm doesn't have
> the concept, so we've been told, of "isolcpus", where a cpu core is
> removed from the schedulers execution pool, and later given the job of
> handling the irq's. This works well on the wintels, but not as
> effectively on the AMD stuff.
>
> My understanding is that you can isolate an arm core but cannot later
> assign it a task until a powerdown reset is done. So code that can
> service an irq on x86-64 in 4 microseconds, can only do it in about 12
> microseconds on arm because a core to do it on has to be selected and
> the context switch performed. Fireing up firefox might extend that lag
> to 200 microseconds, but otherwise the worst case on the rpi4 is around
> 50 microseconds but it might take several minutes to record that big a
> lag with the kernel I'm using. That has not been a problem with the work
> I've done with it.
>
> Is that understanding correct ?
Well I can find people reporting that 'isolcpus' worked on RPi4, but
that core 0 was an exception and could not be isulated (since it is the
boot CPU and the isolation was done before the other cores were booted
it seemed). But it also said 'isolcpus' is deprecated and replaced by
'cpusets'
https://www.kernel.org/doc/html/v5.9/admin-guide/cgroup-v1/cpusets.html
--
Len Sorensen
Reply to: