SMTC Patches [0 of 3]

SMTC Patches [0 of 3]

[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.

Re: SMTC Patches [0 of 3] (how about 4)

[Kevin D. Kissell]

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.

Kevin D. Kissell wrote:
> 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]

[Ralf Baechle]

On Tue, Sep 09, 2008 at 10:27:56PM +0200, Kevin D. Kissell wrote:
> From: "Kevin D. Kissell" <kevink@paralogos.com>
> Date: Tue, 09 Sep 2008 22:27:56 +0200
> To: Linux MIPS Org <linux-mips@linux-mips.org>
> Subject: SMTC Patches [0 of 3]
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> 
> 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.

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

Re: SMTC Patches [0 of 3]

[Kevin D. Kissell]

Ralf Baechle wrote:
> I've folded patch 4/3 into 1/3 and backported everything, as far as
> it seemed sensible. 
Thanks!
> 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.