From owner-freebsd-arch@FreeBSD.ORG  Sat Sep 20 13:00:58 2003
Return-Path: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 0248616A4B3
	for <freebsd-arch@freebsd.org>; Sat, 20 Sep 2003 13:00:58 -0700 (PDT)
Received: from blake.polstra.com (mail.polstra.com [206.213.73.132])
	by mx1.FreeBSD.org (Postfix) with ESMTP id F3C1C43FB1
	for <freebsd-arch@freebsd.org>; Sat, 20 Sep 2003 13:00:56 -0700 (PDT)
	(envelope-from jdp@polstra.com)
Received: from strings.polstra.com (strings.polstra.com [206.213.73.20])
	by blake.polstra.com (8.12.9/8.12.9) with ESMTP id h8KK0sIL015955;
	Sat, 20 Sep 2003 13:00:55 -0700 (PDT)
	(envelope-from jdp@polstra.com)
Message-ID: <XFMail.20030920130054.jdp@polstra.com>
X-Mailer: XFMail 1.5.4 on FreeBSD
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
In-Reply-To: <20030920100911.B55993@xorpc.icir.org>
Date: Sat, 20 Sep 2003 13:00:54 -0700 (PDT)
From: John Polstra <jdp@polstra.com>
To: Luigi Rizzo <rizzo@icir.org>
X-Bogosity: No, tests=bogofilter, spamicity=0.292749, version=0.14.5
cc: freebsd-arch@freebsd.org
Subject: Re: interrupt latency and driver locking
X-BeenThere: freebsd-arch@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Discussion related to FreeBSD architecture
	<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
	<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
	<mailto:freebsd-arch-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sat, 20 Sep 2003 20:00:58 -0000

On 20-Sep-2003 Luigi Rizzo wrote:

> the main problem, as i see it, is that when there are PHY events you
> still need to do some expensive work while holding a lock that
> blocks interrupts, with very bad impact on the worst-case
> response of the system.

I agree that is a problem, but I don't think it is the main problem.
In a running system, PHY events essentially never happen, so it
doesn't matter much if they take a long time.  In other words, the PHY
really only needs attention when the link state changes, and for all
practical purposes that never happens in a running system.

What is killing us is the periodic polling of the PHY every second,
only to find out that nothing has changed.

John