SMTC Patches [0 of 3]
I've managed to steal enough time to rework the SMTC support for the MIPS 34K (and, I suppose 1004K) processors so that it works again near the head of the source tree. This involved a complete rework of the clocking model to be compatible with new common timing event system, which finally enables "tickless" operation in SMTC, something it needed pretty badly. I also solved the problem with using the "wait_irqoff" idle loop under SMTC.
There are going to be three patches that will follow. The first two are relatively localized fixes to problems with FPU affinity and with IPI replay that I came across in testing the new code. The last is a pretty big patch, but it all pretty much hangs together and I couldn't see any sensible way to partition it.
Regards,
Kevin K.
Re: SMTC Patches [0 of 3] (how about 4)
As sometimes happens, after releasing the trio of patches the other night, further testing showed that there was still some quirky FPU-affinity behavior when run on an 34Kf. Further investigation turned up some odd little holes, which I've fixed, but the misbehavior was mostly due to the default number of FP emulations to be performed before declaring a process "FP intensive", which depends on loops_per_jiffy, being so low that "make" was being declared to be an FPU-intensive program. This, too, has been dealt with. I'm going to follow this message with a "Patch 4 of 3" message containig a patch which is meant to be applied after the first 3 - it eliminates a part of patch 1 of 3. It's probably technically feasible to generate a patch that replaces patch 1, but git and I get along poorly enough where I'd probably just make a mess.
Regards,
Kevin K.
Quoted 21 lines · Kevin D. Kissell
I've managed to steal enough time to rework the SMTC support for the MIPS 34K (and, I suppose 1004K) processors so that it works again near the head of the source tree. This involved a complete rework of the clocking model to be compatible with new common timing event system, which finally enables "tickless" operation in SMTC, something it needed pretty badly. I also solved the problem with using the "
wait_irqoff" idle loop under SMTC.There are going to be three patches that will follow. The first two are relatively localized fixes to problems with FPU affinity and with IPI replay that I came across in testing the new code. The last is a pretty big patch, but it all pretty much hangs together and I couldn't see any sensible way to partition it.
Regards,
Kevin K.
Quoted 15 lines · Kevin D. Kissell
From: "Kevin D. Kissell" <[email protected]>
Date: Tue, 09 Sep 2008 22:27:56 +0200
To: Linux MIPS Org <[email protected]>
Subject: SMTC Patches [0 of 3]
Content-Type: text/plain; charset=ISO-8859-1; format=flowedI've managed to steal enough time to rework the SMTC support for the MIPS 34K (and, I suppose 1004K) processors so that it works again near the head of the source tree. This involved a complete rework of the clocking model to be compatible with new common timing event system, which finally enables "tickless" operation in SMTC, something it needed pretty badly. I also solved the problem with using the "
wait_irqoff" idle loop under SMTC.
Quoted 6 lines
There are going to be three patches that will follow. The first two are relatively localized fixes to problems with FPU affinity and with IPI replay that I came across in testing the new code. The last is a pretty big patch, but it all pretty much hangs together and I couldn't see any sensible way to partition it.
I've folded patch 4/3 into 1/3 and backported everything, as far as it seemed sensible. One nit was that 2/3 breaks the build and 3/3 fixes it again. This sort of build breakage is not uncommon but frowned uppon these days since it makes use of git bisect for debugging impossible.
Thanks,
Ralf
Quoted 2 lines · Ralf Baechle
I've folded patch 4/3 into 1/3 and backported everything, as far as it seemed sensible.
Thanks!
Quoted 5 lines
One nit was that 2/3 breaks the build and 3/3 fixes
it again. This sort of build breakage is not uncommon but frowned uppon these days since it makes use of git bisect for debugging impossible.
Oops. I didn't think that 2 required 3, or I wouldn't have published things that way, but I didn't actually do a test build in a separate tree to verify. Sorry about that.
Regards,
Kevin K.