On Mon, Aug 01, 2016 at 07:18:36PM +0200, Jan Kiszka wrote:
> On 2016-08-01 16:05, Gilles Chanteperdrix wrote:
> > On Mon, Aug 01, 2016 at 02:58:54PM +0200, Jan Kiszka wrote:
> >> On 2016-08-01 14:35, Gilles Chanteperdrix wrote:
> >>> On Mon, Aug 01, 2016 at 01:29:46PM +0200, Henning Schild wrote:
> >>>> Hey Gilles,
> >>>>
> >>>> i just checked out the new release, which came as a surprise. Thanks
> >>>> for publishing that!
> >>>>
> >>>> Some of the patches prepare for kernel 4.0+ but one specifically makes
> >>>> sure the combination 4.0+ and 2.6.5 wont work.
> >>>>
> >>>> Am Sat, 9 Jul 2016 15:29:49 +0200
> >>>> schrieb Gilles Chanteperdrix <[email protected]>:
> >>>>
> >>>> ...
> >>>>> hal/x86: forbid compilation with Linux 4.0+
> >>>> ...
> >>>>
> >>>> Could you please provide details on how the FPU support is broken. I am
> >>>> successfully using xenomai 2.6 with 4.1.18 for some time now. I am not
> >>>> sure whether the applications on top use the FPU and if so, if there
> >>>> are multiple FPU-users per core.
> >>>
> >>> The FPU support is broken in the way it detects that Linux was using
> >>> FPU in kernel-space (for RAID, or memcpy on oldish AMD processors,
> >>> geode, K6, etc...) when Linux gets preempted. We can no longer rely
> >>> on checking the bit TS in CR0, and need instead to use an accessor
> >>> that was added in the I-pipe patch to know that. For details, see
> >>> the changes that were made to FPU support for x86 in Xenomai 3.x.
> >>>
> >>
> >> Are we doing eager switching there already? Would allow to use things
> >> as-is (i.e. without having to trap FPU accesses) on CPUs that are recent
> >> enough to do this switching lazily in hardware.
> >
> > The problem has nothing to do with trapping FPU accesses or eager
> > switching. Xenomai has always done eager switching. Xenomai 3 traps
> > fpu access in order to arm the XNFPU bit on first fpu use and then
> > does eager switching as usual.
>
> Eager means always switch on flipping the context, irrespective of the
> previous usage. There is no trapping of FPU usage anymore then. Hardware
> does this much faster today when using xsave. Therefore upstream moved
> away from the lazy pattern apparently also still used in Xenomai.
besides, optimizing the case of high-end does not really make sense
for Xenomai. We prefer to optimize the case of low-end, even if it
has a small cost for high-end. We target good worst case, remember?
--
Gilles.
_______________________________________________
Xenomai mailing list
[email protected]
https://xenomai.org/mailman/listinfo/xenomai
