From owner-freebsd-current Sat May 16 14:56:32 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA14372 for freebsd-current-outgoing; Sat, 16 May 1998 14:56:32 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from smtp02.primenet.com (daemon@smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA14362 for ; Sat, 16 May 1998 14:56:26 -0700 (PDT) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id OAA12102; Sat, 16 May 1998 14:56:28 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp02.primenet.com, id smtpd012080; Sat May 16 14:56:22 1998 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id OAA13331; Sat, 16 May 1998 14:56:20 -0700 (MST) From: Terry Lambert Message-Id: <199805162156.OAA13331@usr02.primenet.com> Subject: Re: cvs commit: src/sys/conf param.c src/sys/kern uipc_domain.c uipc_proto.c uipc_socket.c uipc_socket2.c uipc_usrreq.c src/sys/ To: wollman@khavrinen.lcs.mit.edu (Garrett Wollman) Date: Sat, 16 May 1998 21:56:20 +0000 (GMT) Cc: eivind@yes.no, wollman@khavrinen.lcs.mit.edu, current@FreeBSD.ORG In-Reply-To: <199805161751.NAA09343@khavrinen.lcs.mit.edu> from "Garrett Wollman" at May 16, 98 01:51:48 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > What would be necessary to make it possible for this to be a dynamic > > datastructure, instead of having a maximum limit? > > Can't be done. The limit is there because we can't expand the VM > space the zone allocator uses at interrupt time. Dyson can probably > explain why this is. It's because you can't say "WAITOK" on an allocation, and you can't have the allocation fail. Depending on the driver, you can get around this problem. The basic assumption is that you know that you won't be getting another real interrupt until you have serviced the previous real interrupt. This obviously won't work with FASTINTR devices, which are assumed to run to completion at interrupt time, and so are not tightly coupled. The way you would do this is, before exiting the soft interrupt that resulted from a hard interrupt, you preallocate on behalf of the driver. This allows it to be sure that it will have the resource when it needs it, at hard interrupt time, but the allocation does not block at high SPL. This is somewhat problematic in the case of shared interrupts, since it can delay all drivers hooked to a particular hardware interrupt, since hardware interrupts are not reenabled until the soft interrupt has completed processing. One fix for this is the use an "accelerated soft interrupt". To do this, you would allocate a small pool, and front-load any hardware interaction in the driver, and re-enable the hard interrupt as early as possible. For what it's worth, Windows95 and WindowsNT have the same restrictions, and are probably more aggressive about early release of shared hard interrupts than FreeBSD is. Doesm't make them faster, though that's totally unrelated to the merit of the design (which is a good idea, overall). }B-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message