From mboxrd@z Thu Jan 1 00:00:00 1970 References: <55E5E453.1080400@xenomai.org> <55E5F849.1070708@xenomai.org> <55E5FB89.3080604@xenomai.org> <55E60743.30600@xenomai.org> <5604517A.2000602@mperpetuo.com> <20150925150248.GE1332@hermes.click-hack.org> From: Dmitriy Cherkasov Message-ID: <560580E6.6070208@mperpetuo.com> Date: Fri, 25 Sep 2015 10:14:14 -0700 MIME-Version: 1.0 In-Reply-To: <20150925150248.GE1332@hermes.click-hack.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai] xenomai/ipipe arm64 port List-Id: Discussions about the Xenomai project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gilles Chanteperdrix Cc: "xenomai@xenomai.org" Hi Gilles, Thank you for the feedback. Yes, I saw that the armv7 design had trapped FPU usage and switched context then. While this is good for performance of threads that never use the FPU, it may introduce a one-time delay for threads that do, which may not be desirable in a real-time system. I haven't had a chance to measure the specific delay, so I am not sure what the real impact is. Also, since Linux does not currently support lazy switching, we would have to make sure the FPU is enabled (meaning FPU access traps are disabled) every time we switch back to the kernel. As far as I can tell, the FPU in Linux is always on for arm64. This is in contrast to armv7, where it was okay to return to the kernel with FPU traps enabled. -Dmitriy On 09/25/2015 08:02 AM, Gilles Chanteperdrix wrote: > On Thu, Sep 24, 2015 at 12:39:38PM -0700, Dmitriy Cherkasov wrote: >> Hello, >> >> I've added some basic FPU support. It does not do lazy switching, since >> this is not supported in the arm64 kernel yet. > Xenomai only does lazy switching for the first use of FPU by a task, > but then switches eagerly: a user-space task is always created > without the XNFPU bit. Its first use of FPU causes a fault, which > then switches FPU context, and set the XNFPU bit. Starting from > there, every context switch to this tasks switches the FPU context. > >> I've tested it >> successfully with switchtest. Below is a pull request if you guys are >> interested in picking this up. >> >> -Dmitriy >> >> The following changes since commit 17095784c6d3d44dc7f1512ffab9bb957e298466: >> >> cobalt/arm64: leave mm tracking to the pipeline (2015-09-17 15:08:34 >> +0200) >> >> are available in the git repository at: >> >> http://gitlab.mperpetuo.com/it/xenomai-3.git arm64-fp >> >> for you to fetch changes up to 4825d1c170b773e82f90dd15409dde489447301e: >> >> cobalt/arm64: add basic FPU support (2015-09-24 12:04:42 -0700) > Just had a look. It looks fine, except that: > > - you should not set the XNFPU bit in xnarch_init_shadow_tcb, > this has been done by the upper layers > (kernel/cobalt/posix/thread.c, function pthread_create) for user > threads, and some kernel threads do not set the XNFPU bit when they > do not use the FPU > > - you do not need to set it in xnarch_switch_fpu either: > xnarch_switch_fpu is only called for tasks which have the XNFPU bit > set (kernel/cobalt/thread.c function xnthread_switch_fpu). > > - the context switch should set or clear a hardware bit somewhere to > cause any use of the FPU to cause a trap: some threads do not have > the XNFPU bit (some kernel threads), and you want any FPU use by > these threads to cause a trap rather than clobbering the fpu > context. Note that switchtest does not allow to test this case. This > bit should be flipped when loading the FPU context for a thread > which has the XNFPU bit. > > Note that the last point requires modifying the I-pipe for arm64 to > emit I-pipe events when entering a fault caused by any FPU use. But > this modification is mandatory anyway, you also need it to handle > gracefully the FPU exceptions (div by zero, etc...). > > And once you have that modification done, modifying the code to do > lazy switching for the first fault is not hard. > > If you agree, I can propose patches for I-pipe and Xenomai to do > that, and let you test if it works. >