'make -j16 universe' gives SIReset

Kostik Belousov kostikbel at gmail.com
Wed Aug 17 10:26:48 UTC 2011


On Wed, Aug 17, 2011 at 11:45:41AM +0200, Marius Strobl wrote:
> On Wed, Aug 17, 2011 at 07:48:20AM +1000, Peter Jeremy wrote:
> > On 2011-Aug-13 16:38:07 +0200, Marius Strobl <marius at alchemy.franken.de> wrote:
> > >Could you please give the following patch with SCHED_4BSD (cpu_switch()
> > >still is missing support for SCHED_ULE) with something like -j128
> > >buildworlds a try on your V890?
> > >http://people.freebsd.org/~marius/sparc64_replace_sched_lock_w_atomic.diff
> > 
> > Getting better but still not perfect.  It survived a couple of -j128
> > buildworlds with another six -j16 buildworlds running in parallel.
> 
> Thanks!
> 
> > 
> > But it still has the same issue pho's stress test - a thr1 process is
> > blocked in urdlck.  The improvement is that there's only one stuck
> > process and it took 7? hrs at INCARNATIONS=150 instead of 1-2 hours.
> > (And it runs out of witness locks).
> > 
> 
> Well, the sole purpose of that patch is to get rid of the MD sched_lock
> usage in order to be able to add support for SCHED_ULE in a next step.
> It's not obvious why this should have an impact on the problem with
> userland mutex code. In fact using sched_lock provided more protection
> than solving this via atomic operations, which should still be sufficient
> for what we need to guarantee though. If at all I'd expect the patch to
> create problems in case I've overlooked something, not to solve any :)
> If it indeed has a positive impact on the the userland mutex problem then
> my best guess is that this is a side-effect of the memory barriers the
> patch adds to the context switching. That would indicate that the cause
> of the problem in fact are missing memory barriers in the userland mutex
> code, which IMO is one of the suspicious things regarding that code.

I am sorry for not answering your direct mail about the issue.

As an experiment, you might add an explicit full barriers into the end
of the user-mode lock/unlock routines and see what happens next.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-sparc64/attachments/20110817/a32a0d58/attachment.pgp


More information about the freebsd-sparc64 mailing list