[Top] [All Lists]

Re: SMTC support status in latest git head.

To: Anoop P A <>
Subject: Re: SMTC support status in latest git head.
From: "Kevin D. Kissell" <>
Date: Sat, 25 Dec 2010 07:17:03 -0800
Cc: STUART VENTERS <>, "Anoop P.A." <>,
Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=default;; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-Source:X-Source-Args:X-Source-Dir; b=HMdMBmmMnDGtlJmyE4eiPzoHagsnMSwzAEGkeAdwVucEK/RwqfKv1ilMzpRBFhoTVk4K36jBwSueBDV2dpqm679d7aMEeaXCspMtDz0nHUJdEI6j1V9ETcNWFp/9JE2D;
In-reply-to: <1293262341.27661.188.camel@paanoop1-desktop>
Original-recipient: rfc822;
References: <> <> <1293201545.27661.55.camel@paanoop1-desktop> <> <1293206536.27661.63.camel@paanoop1-desktop> <> <1293262341.27661.188.camel@paanoop1-desktop>
User-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv: Gecko/20101207 Thunderbird/3.1.7
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

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.

<Prev in Thread] Current Thread [Next in Thread>