Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 9 Mar 2001 10:57:25 -0800 (PST)
From:      Matthew Jacob <mjacob@feral.com>
To:        John Baldwin <jhb@FreeBSD.ORG>
Cc:        alpha@FreeBSD.ORG
Subject:   RE: cvs commit: src/sys/alpha/include mutex.h src/sys/i386/inclu
Message-ID:  <Pine.LNX.4.21.0103091057000.21042-100000@zeppo.feral.com>
In-Reply-To: <XFMail.010308233451.jhb@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help

Hey! Sounds good! 

Now I feel better at looking at an UltraSparc port.... (as if!)


> 
> On 09-Mar-01 John Baldwin wrote:
> > jhb         2001/03/08 23:24:17 PST
> > 
> >   Modified files:
> >     sys/alpha/include    mutex.h 
> >     sys/i386/include     mutex.h 
> >     sys/ia64/include     mutex.h 
> >     sys/kern             kern_mutex.c kern_fork.c 
> >     sys/sys              proc.h 
> >   Log:
> >   Fix mtx_legal2block.  The only time that it is bad to block on a mutex is
> >   if we hold a spin mutex, since we can trivially get into deadlocks if we
> >   start switching out of processes that hold spinlocks.  Checking to see if
> >   interrupts were disabled was a sort of cheap way of doing this since most
> >   of the time interrupts were only disabled when holding a spin lock.  At
> >   least on the i386.  To fix this properly, use a per-process counter
> >   p_spinlocks that counts the number of spin locks currently held, and
> >   instead of checking to see if interrupts are disabled in the witness code,
> >   check to see if we hold any spin locks.  Since child processes always
> >   start up with the sched lock magically held in fork_exit(), we initialize
> >   p_spinlocks to 1 for child processes.  Note that proc0 doesn't go through
> >   fork_exit(), so it starts with no spin locks held.
> >   
> >   Consulting from:    cp
> 
> This is actually very good for the alpha, as the mtx_legal2block() that had
> been in alpha/include/mutex.h was bogus.  Also, with this out of the way, any
> plans to disable interrupts via IPL for interrupt threads are now quite
> feasible, as well as for any other architectures which don't allow us to disable
> interrupts via PIC masks but only via the CPU.  However, if we can selectively
> disable interrupts on PICs or other controllers and allow other interrutps to
> trigger while we continue to run in the kernel, we need to try and do that, as
> it greatly improves interrupt latency.  This will become more apparent when
> Giant becomes more split up, as currently, almost all of the kernel effectively
> blocks interrupts by virtue of holding Giant.
> 
> So, yes, Matt, you were right in that counting on being able to disable
> interrupts outside of the CPU is not valid, and it was not indeed part of the
> original SMPng design, but was something I had read in to a cheesy
> mtx_legal2block() that was valid on the i386.
> 
> 


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-alpha" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.21.0103091057000.21042-100000>