Date: Tue, 14 Jun 2011 09:51:44 +1000 From: Peter Jeremy <peterjeremy@acm.org> To: Marius Strobl <marius@alchemy.franken.de> Cc: freebsd-sparc64@freebsd.org Subject: Re: 'make -j16 universe' gives SIReset Message-ID: <20110613235144.GA12470@server.vk2pj.dyndns.org> In-Reply-To: <20110608224801.GB35494@alchemy.franken.de> References: <20110526234728.GA69750@server.vk2pj.dyndns.org> <20110527120659.GA78000@alchemy.franken.de> <20110601231237.GA5267@server.vk2pj.dyndns.org> <20110608224801.GB35494@alchemy.franken.de>
next in thread | previous in thread | raw e-mail | index | archive | help
--82I3+IH0IqGh5yIs Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2011-Jun-09 00:48:01 +0200, Marius Strobl <marius@alchemy.franken.de> wr= ote: >This might be due to the excessive use of sched_lock by SCHED_4BSD >and the MD code, f.e. more CPUs means less TLB contexts per CPU which >in turn means more flushes that are protect by sched_lock. I have noticed that systat reports very high trap & fault counts. > It would >be great if the machine wouldn't lock up so you could check what >exactly is holding the mutex so long. Agreed. >I think meanwhile I had a sound idea how to achieve the necessary level >of protection in the MD code using just atomic operations instead of >sched_lock, which further down would also allow the use of SCHED_ULE. Sounds good - let me know if there's anything I can do to help. >> I tried adding this and the system survived a "make -j30 universe" on >> -stable (BTW "make universe" seems to have issues cross-building x86 >> derivatives). I'm now trying that on -current. I'm not sure what the >> implications of the above change are. >>=20 > >What was the outcome of these tests? I got a "spinlock held too long" panic that should have gone to DDB but the system wouldn't respond to anything other than a RSC reset. >Nevertheless it also would be interesting to know if you end up >with a corrupt kernel stack with DDB, KDB and r222840 in place, >especially in case disabling superscalar dispatch doesn't solve >the problem. I'm building r223035 with DDB & KDB and will see how that goes. --=20 Peter Jeremy --82I3+IH0IqGh5yIs Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iEYEARECAAYFAk32opAACgkQ/opHv/APuIfDjwCglHNX72XewKJU2nvc732O35Bn +T8An06Ah+gMKdgE73uTKdyAjYSkeF7H =Tpfy -----END PGP SIGNATURE----- --82I3+IH0IqGh5yIs--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110613235144.GA12470>