Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 20 Apr 2010 11:33:48 +0100
From:      Rui Paulo <rpaulo@freebsd.org>
To:        "C. Jayachandran" <c.jayachandran@gmail.com>
Cc:        freebsd-mips@freebsd.org
Subject:   Re: SMP support for XLR processors.
Message-ID:  <BC57A6F0-4F2E-47F4-92BF-849AD18FC004@freebsd.org>
In-Reply-To: <7BEFA3F5-97AE-477C-9DD3-EF1C4B7DCEB0@freebsd.org>
References:  <w2z98a59be81004171540t2f0d5193nca2ec9e2540502e2@mail.gmail.com> <544BD79C-24C0-4015-AE04-F7F8D70CF537@freebsd.org> <DEF66A16-B4B8-4459-87C7-B695813FB68C@freebsd.org> <A1FC32B9-1105-43C5-91C1-C4A81F78066B@lakerest.net> <3BCD65EB-B997-449D-864C-CA24C7B19026@freebsd.org> <CFE92A18-C834-45C5-B18C-7F62437D1A2B@lakerest.net> <z2z98a59be81004190411hd4bee7e4t6e5eed3d3789180a@mail.gmail.com> <6BDB3874-D779-45A6-ABAE-4C331D78A189@lakerest.net> <y2m98a59be81004190657kce2488b0p86a725b1175cb14b@mail.gmail.com> <l2n98a59be81004200252lf1d0a372pfae8ac5f55440e58@mail.gmail.com> <7BEFA3F5-97AE-477C-9DD3-EF1C4B7DCEB0@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On 20 Apr 2010, at 11:05, Rui Paulo wrote:

> On 20 Apr 2010, at 10:52, C. Jayachandran wrote:
>=20
>> On Mon, Apr 19, 2010 at 7:27 PM, C. Jayachandran
>> <c.jayachandran@gmail.com> wrote:
>>> I have a possible cause for the panic with invariants - we should =
not
>>> schedule the msgring threads unless the smp is completely up. I =
guess
>>> we start getting message ring interrupts on before the message ring
>>> threads can be scheduled.  I am trying out some changes for this -
>>> will send you a patch if this fixes it.
>>=20
>> I've attached a patch that should fix the issue. The cause was the =
way
>> message ring threads are started on individual cores and the way
>> interrupts are enabled in the core.  I've moved starting message ring
>> threads on other cpus to be a SYSINIT after SMP is started.  I'd
>> thought originally that it was due to some clash with the changes in
>> HEAD - but looks like I was completely off-track there.
>>=20
>> Please let me know if you don't get multi-user with 32 cpus with this
>> patch. There is still the original hang in buildworld, but that =
should
>> be a bug elsewhere
>>=20
>> I have a copy at http://sites.google.com/site/cjayachandran/files too
>=20
> This works perfectly, thanks!

On further inspection, I noticed that the load avg is now 7.

last pid:  1613;  load averages:  6.99,  6.97,  6.08    up 0+00:30:11  =
10:32:48
108 processes: 40 running, 24 sleeping, 44 waiting
CPU:  0.0% user,  0.0% nice, 21.9% system,  0.0% interrupt, 78.1% idle
Mem: 8444K Active, 6028K Inact, 37M Wired, 308K Cache, 6800K Buf, 3190M =
Free
Swap:=20

  PID USERNAME  THR PRI NICE   SIZE    RES STATE   C   TIME   WCPU =
COMMAND
   10 root       32 171 ki31     0G     0G CPU0    0 263:26 2500.00% =
idle
   17 root        1 -16    -     0K     0G CPU12   2   0:00 100.00% =
msg_intr12
   15 root        1 -16    -     0K     0G CPU4    2   0:00 100.00% =
msg_intr4
   16 root        1 -16    -     0K     0G CPU8    2   0:00 100.00% =
msg_intr8
   20 root        1 -16    -     0K     0G CPU24   1   0:00 100.00% =
msg_intr24
   19 root        1 -16    -     0K     0G CPU20   1   0:00 100.00% =
msg_intr20
   21 root        1 -16    -     0K     0G CPU28   1   0:00 100.00% =
msg_intr28
   18 root        1 -16    -     0K     0G CPU16   1   0:00 100.00% =
msg_intr16

What are these msg_intrXX kprocs doing?

Regards,
--
Rui Paulo





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BC57A6F0-4F2E-47F4-92BF-849AD18FC004>