On 08/30/11 04:16, Edgar E. Iglesias wrote:
> On Mon, Aug 29, 2011 at 05:35:44PM -0700, Kevin D. Kissell wrote:
>> On 08/29/11 17:14, David Daney wrote:
>>> On 08/29/2011 04:55 PM, Kevin D. Kissell wrote:
>>>> I submitted that exact patch (David's more minimal version) in December
>>>> 2010 (and I did test it). Did it not take?
>>> Evidently not. Perhaps Ralf will see fit to commit it this time.
>> Looking back over the exchange and thinking about the date,
>> in all fairness to Ralf, when I submitted it, it was a diff -u and
>> not a git diff, because I was at my brother-in-law's house for
>> the holidays and had no access to my MIPS Linux git machine.
>> It got picked up by patchwork.linux-mips.org ( patch/1896 ),
>> but was only actually tested by Anoop a couple of days
>> later. He confirmed that it solved the problem, but also that
>> there were other problems with SMTC in the then-current
>> head, apparently relating to timekeeping_notify(). Those
>> problems weren't resolved in the context of that email thread,
>> so the patch - something along the lines of which really and
>> truly is necessary - may have been ignored as a partial fix,
>> even though it is a self-contained solution to a self-contained bug.
> Interesting. Coincidentally, after getting pass the CP0_Status issue, I ran
> into some issues related to time-keeping, but I got the impression I was
> seeing a mix of problems with QEMU and possibly the kernel. I never hunted
> these issues down though. Maybe I'll give it a go some other time..
It could very well have been a QEMU issue. At the time, I did spend
a while staring at the diffs between the working and non-working
kernel sources and I was unable to spot anything obviously suspect.
> It makes me wonder, what is the state of SMTC kernels? Are they widely
> used and considered stable?
> Or is the SMP mode (1 TC per VPE) the common choice?
The virtual SMP mode is far more common. SMTC has the advantage
that it allows the maximum throughput to be extracted from a 34K
core - depending on the application/benchmark, the "sweet spot"
may be more than 2 concurrent threads - but it's less well maintained.
Regards,
Kevin K.
