On 12/24/10 11:32 PM, Anoop P A wrote:
On Fri, 2010-12-24 at 15:34 -0800, Kevin D. Kissell wrote:
Ah, well, at least we have a stackframe.h fix that preserves David's
performance tweak for the deeper pipelined processors. In looking for
this, I did notice that someone did some modification to the SMTC clock
tick logic that I was skeptical had ever been tested. If you've still
got that kernel binary handy, you might check to see if it boots with
maxtcs=1 maxvpes=1, maxtcs=2 maxvpes=1, and/or maxtcs=2 maxvpes=2.
Yes I have tried with various combinations of tcs and vpes. with
maxvpes=1 I can boot with a max of 4 TCS ( VPE0 has 4 TCs) .
However setting maxpes=2 and maxtcs=2 hangs pretty early.
Clock rate set to 600000000
console [ttyS0] enabled
Calibrating delay loop... 398.33 BogoMIPS (lpj=796672)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 512
Limit of 2 VPEs set
Limit of 2 TCs set
TLB of 64 entry pairs shared by 2 VPEs
VPE 0: TC 0, VPE 1: TC 1
IPI buffer pool of 32 buffers
CPU revision is: 00019548 ((null))
TC 1 going on-line as CPU 1
Brought up 2 CPUs
One strange observation is with maxtcs=3 and maxvpes=2 kernel boots all
the way.
Again with maxtcs=5 and maxvpes=2 it hangs after switching to MIPS
clocksource.
I strongly suspect some issue with locking. I will dig the code early
next week.
If locking is screwed up, I'd expect more problems with 4 TC "CPUs" in
the same VPE. It also suggests that the basic distribution via local
low-latency IPI within a VPE is functioning, but that something is
broken in the cross-VPE evengt propagation. I strongly suspect that
your maxtcs=3, maxvpes=2 case would hang sooner or later, but by luck of
the draw none of the init threads got scheduled on VPE 1 long enough to
get stuck.
I note that there were some changes made under the rubric "MIPS: SMTC:
Avoid queueing multiple reschedule IPIs" in October and November of last
year that make me nervous. I wouldn't have coded things that way
myself, but they might be OK. Still, the first bisection I'd make if I
was trouble-shooting this would be to roll back to just before they went in.
Ho, ho, ho,
Kevin K.
