From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nick Garnett To: ecos-discuss@sourceware.cygnus.com Subject: Re: [ECOS] On demand FP context switch major problem. Date: Thu, 18 May 2000 06:30:00 -0000 Message-id: References: <87u2fwt559.fsf@osv.javad.ru> X-SW-Source: 2000-05/msg00161.html Sergei Organov writes: > Hello, > > I've almost finished the "on demand" FP context switch support in the PowerPC > HAL, but at the end faced with a problem for which I don't see a reasonable > solution. Here is the description of the problem. > > To switch FP context on demand we need to disable FP in the usual context > switch routine by means of clearing the "FP enable" bit in the MSR. It means > that at thread level of execution the FP bit in the MSR could be cleared any > time if scheduler isn't locked and/or interrupts aren't disabled. It in turn > means that in thread code we can safely change MSR only if above condition(s) > is(are) met. But the EE (external interrupt enable) bit is also located in the > MSR, so it's unsafe to disable interrupts if scheduler isn't locked! > > The above has unfortunate consequences for the code in the > HAL_DISABLE_INTERRUPTS macro. With "on demand" FP context switch is used, this > macro should somehow lock the scheduler before reading the MSR and then unlock > it back after writing the MSR :-( > > The above discussion didn't take into consideration support for the use of FPU > in the interrupt handlers (ISRs/DSRs). If this support is added, then even > locking of the scheduler doesn't help. In this case only disabling of > interrupts gives us a safe way to change MSR, but once again disabling of > interrupts needs changing of MSR :-( > > Any suggestions? Hopefully I'm just missing something obvious. This is one of the annoying features of the PowerPC, and other RISC processors, that "global" state and "per-thread" state are mixed up in the same register. One option would be to always clear the FP enable bit in HAL_DISABLE_INTERRUPTS (probably HAL_ENABLE_INTERRUPTS and HAL_RESTORE_INTERRUPTS too). This would make your described scenario work correctly since you would get an FP exception at step 7. In the simple case you would also get an FP trap on the next FP instruction, which would see that the current thread is already the FPU owner and just set the FP enable bit. Taking the extra trap is unpleasant, but with a suitable fast path it should not be too expensive. It is unlikely that code which plays with the interrupt enable is also doing a lot of floating point, and the thread may well be timesliced or preempted before moving from one to the other anyway. So the chances are that this will not result in any more FP traps than before. There has to be a FP trap per thread switch anyway, and changing the interrupt enable should be a lot less common than that. -- Nick Garnett Cygnus Solutions, a Red Hat Company Cambridge, UK From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nick Garnett To: ecos-discuss@sources.redhat.com Subject: Re: [ECOS] On demand FP context switch major problem. Date: Wed, 05 Sep 2001 00:10:00 -0000 Message-ID: References: <87u2fwt559.fsf@osv.javad.ru> X-SW-Source: 2001-09/msg00075.html Message-ID: <20010905001000.rFHRGzkCQ4LKBR-eq5xdaMsXjkdkSlPovsTmKmYUoIQ@z> Sergei Organov writes: > Hello, > > I've almost finished the "on demand" FP context switch support in the PowerPC > HAL, but at the end faced with a problem for which I don't see a reasonable > solution. Here is the description of the problem. > > To switch FP context on demand we need to disable FP in the usual context > switch routine by means of clearing the "FP enable" bit in the MSR. It means > that at thread level of execution the FP bit in the MSR could be cleared any > time if scheduler isn't locked and/or interrupts aren't disabled. It in turn > means that in thread code we can safely change MSR only if above condition(s) > is(are) met. But the EE (external interrupt enable) bit is also located in the > MSR, so it's unsafe to disable interrupts if scheduler isn't locked! > > The above has unfortunate consequences for the code in the > HAL_DISABLE_INTERRUPTS macro. With "on demand" FP context switch is used, this > macro should somehow lock the scheduler before reading the MSR and then unlock > it back after writing the MSR :-( > > The above discussion didn't take into consideration support for the use of FPU > in the interrupt handlers (ISRs/DSRs). If this support is added, then even > locking of the scheduler doesn't help. In this case only disabling of > interrupts gives us a safe way to change MSR, but once again disabling of > interrupts needs changing of MSR :-( > > Any suggestions? Hopefully I'm just missing something obvious. This is one of the annoying features of the PowerPC, and other RISC processors, that "global" state and "per-thread" state are mixed up in the same register. One option would be to always clear the FP enable bit in HAL_DISABLE_INTERRUPTS (probably HAL_ENABLE_INTERRUPTS and HAL_RESTORE_INTERRUPTS too). This would make your described scenario work correctly since you would get an FP exception at step 7. In the simple case you would also get an FP trap on the next FP instruction, which would see that the current thread is already the FPU owner and just set the FP enable bit. Taking the extra trap is unpleasant, but with a suitable fast path it should not be too expensive. It is unlikely that code which plays with the interrupt enable is also doing a lot of floating point, and the thread may well be timesliced or preempted before moving from one to the other anyway. So the chances are that this will not result in any more FP traps than before. There has to be a FP trap per thread switch anyway, and changing the interrupt enable should be a lot less common than that. -- Nick Garnett Cygnus Solutions, a Red Hat Company Cambridge, UK