Re: Feedback from the community -> ARM
On Friday 11 June 2021 05:34:53 Arnd Bergmann wrote:
> On Thu, Jun 10, 2021 at 4:43 PM Uwe Kleine-König
<uwe@kleine-koenig.org> wrote:
> > Is there anything on your mind that is missing above and that you'd
> > like to be shared with ARM? Feel free to reply here or discuss in
> > #debian-arm. (I'm ukleinek there.)
>
> I'll be at the meeting as well, and one point I would want to bring up
> is support for 32-bit binaries on 64-bit kernels. This has come up a
> few times on #debian-arm, and the problem is a mismatch between which
> obsolete instructions are emulated depending on the kernel: 64-bit
> kernels emulate all the instructions that were removed in v8 (setend,
> cp15 barriers, swp), while 32-bit kernels emulate instructions that
> were already needed in v7 (swp, mrc tlsreg, unaligned
> ldm/stm/ldrd/strd). This means that some binaries that ran fine on an
> ARMv7 processor may break when running on an ARMv8 processor with a
> 32-bit kernel, while other binaries may break on the same hardware on
> a 64-bit kernel.
>
> This situation is bad for Debian as there are mixed messages regarding
> what users should actually run on ARMv8 hardware and what should
> be tested. My hope is that we can find an agreement regarding which
> of the emulation code we actually want on v8 processors and then make
> sure that every binary that can run on a 32-bit kernel can also run on
> a 64-bit kernel (but not necessarily the other way round). This could
> mean adding features to arch/arm64/ that have previously been
> rejected, or artificially crippling the emulation code in arch/arm/
> when running on v8 to force user space applications to get fixed.
>
> Side note: yes, 32-bit user space code is still important to run for
> a lot of users, especially in low-memory configurations, but support
> for 32-bit kernels is unavailable on most newer CPU cores and
> somewhat lacking even on older cores (missing errata workarounds
> and certain features of 64-bit kernels).
>
And while discussing that, emphasize that some of us are running 32 bit
armhf because the stack frame is smaller when switching context, giving
better, measurable latency responses which are extremely important if
driving a stepper motor by software generated steps. It is not uncommon
to see an 80% speed loss when driving steppers by software steppers
compared to driving them with programmable fpga hardware. A 10
microsecond wobble in the step timing can cost us 50% of the motors
torque. 100 microseconds brings the motor to a complete stop but
bouncing back and forth in the magnetic grip, and if the next step
arrives when the motor is backing up, it can't accellerate to get back
in position, the part being made is ruined, and the motor is stalled,
losing track of its home position so the whole machine has to be
rehomed. That costs money in time wasted recovering, in raw materiel
ruined, and potentially broken and expensive tooling.
Going to pure 64 bit systems effectively means you are locking a large
percentage of the cnc manufacturing on this planet out in the parking
lot because we can't tolerate the loss of performance in real time that
bigger stack frame causes unless we spend an additional $200+ on
hardware interfaces to get that performance back. We may as well use a
bigger, uses 20x the power but its cheaper pc. I'm doing it both ways,
but my shop isn't commercial, its hobbiest. I don't have to make xx
dollars per hour for a living.
One old farts $0.02.
> Arnd
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>
Reply to: