From owner-freebsd-arch  Tue Dec 18  6:24:57 2001
Delivered-To: freebsd-arch@freebsd.org
Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16])
	by hub.freebsd.org (Postfix) with ESMTP id 131FB37B41C
	for <arch@FreeBSD.ORG>; Tue, 18 Dec 2001 06:24:53 -0800 (PST)
Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102])
	by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id BAA00908;
	Wed, 19 Dec 2001 01:24:41 +1100
Date: Wed, 19 Dec 2001 01:25:58 +1100 (EST)
From: Bruce Evans <bde@zeta.org.au>
X-X-Sender:  <bde@gamplex.bde.org>
To: Luigi Rizzo <rizzo@aciri.org>
Cc: <arch@FreeBSD.ORG>
Subject: Re: swi_net
In-Reply-To: <20011213091957.B39991@iguana.aciri.org>
Message-ID: <20011219010205.P4481-100000@gamplex.bde.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-arch@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-arch.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-arch>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-arch>
X-Loop: FreeBSD.ORG

On Thu, 13 Dec 2001, Luigi Rizzo wrote:

> we have 2 slightly different versions of swi_net in -current and
> -stable, listed below (STABLE/Alpha is approximately the same as
> CURRENT).
>
> I like a lot the semantics of the version in -stable, because it
> enforces a strict priority in the execution of soft handlers
> (remember they are not preemptable), even when schednetisr(FOO) is
> called within one of the handlers.

I prefer the -stable version too, but I think the strict priority
doesn't make much difference.  Anyway, it's not completely strict,
because lower priority handlers are not preemptable.

> However I was wondering if there are objections in changing the
> first line of the CURRENT version in
>
>         for (; bits = atomic_readandclear_int(&netisr); )
>
> so that we process all pending handlers without exiting from the
> function and have a closer approximation of what STABLE does.

It can't hurt, but I think it is only a tiny improvement.  If another
netisr is scheduled after the above atomic operation, then swi_net()
will always be called again (from ithread_loop()) soon after it returns.
We can't even avoid the overhead for the loop and the call unless several
calls are coalesced.  Other overheads in -current are relatively huge.

> --------- u2/HEAD/src/sys/kern/kern_intr.c -----------------
> static void
> swi_net(void *dummy)
> {
>         u_int bits;
>         int i;
>
>         bits = atomic_readandclear_int(&netisr);
>         while ((i = ffs(bits)) != 0) {
>                 i--;
>                 if (netisrs[i] != NULL)
>                         netisrs[i]();
>                 else
>                         printf("swi_net: unregistered isr number: %d.\n", i);
>                 bits &= ~(1 << i);
>         }
> }
>
>
> ----- STABLE/src/sys/i386/isa/ipl.s -----
>
> swi_net:
>         MCOUNT
>         bsfl    _netisr,%eax
>         je      swi_net_done
> swi_net_more:
>         btrl    %eax,_netisr
>         jnc     swi_net_next
>         call    *_netisrs(,%eax,4)
> swi_net_next:
>         bsfl    _netisr,%eax
>         jne     swi_net_more
> swi_net_done:
>         ret

-current is also missing the optimization of initializing the table with
dummies so that it doesn't need to check the pointer.  Unexpected netisrs
could be handled even better by panicing for them.

Bruce


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