Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 3 May 2004 13:35:51 +1000 (EST)
From:      Bruce Evans <bde@zeta.org.au>
To:        "M. Warner Losh" <imp@bsdimp.com>
Cc:        freebsd-current@freebsd.org
Subject:   Re: sio: lots of silo overflows on Asus K8V with Moxa Smartio C104H/PCI
Message-ID:  <20040503131929.K3770@gamplex.bde.org>
In-Reply-To: <20040502.111815.74057370.imp@bsdimp.com>
References:  <20040430102504.477152ce.bm@malepartus.de> <20040502130027.O1806@gamplex.bde.org> <20040502.111815.74057370.imp@bsdimp.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 2 May 2004, M. Warner Losh wrote:

> In message: <20040502130027.O1806@gamplex.bde.org>
>             Bruce Evans <bde@zeta.org.au> writes:
> : No, but siointr() doesn't go near the tty layer or almost any other
> : layer.  It uses pseudo-dma and schedules a SWI to transfer data between
> : its buffers and the tty layer.  Fast interrupt handlers cannot call
> : other layers because they cannot reasonable lock other layers or
> : vice versa.  (Even the call to the scheduler to schedule a SWI in the
> : current implementation is a layering violation.)
>
> So it is also safe to call the tty layer w/o giant held from the SWI?
> I guess that was my question.  Or is the SWI wrapped in Giant when I
> wasn't looking...

Unsafe.  SWIs are wrapped by Giant unless they are created using
swi_add(... INTR_MPSAFE ...).  There are 26 calls to swi_add() in the
tree, and the slow progress of Giant removal is shown by only 3 of
these using INTR_MPSAFE.  The ones in sio are not in the 3.  The 3
are all just for multiplexors that push down deciding whether to use
Giant to lower layers:
- softclock: handles timeout.  CALLOUT_MPSAFE specifies that Giant
  is not needed (or has been pushed down further) for individual
  timeouts.
- swi_net: calls netisrs.  NETISR_MPSAFE specifies that Giant is not
  needed (or ...) for individual netisrs.
- taskqueue_swi_run: calls queued MPSAFE tasks.  Non-MPSAFE tasks are
  on another queue.

Bruce



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040503131929.K3770>