Date: Sat, 16 May 1998 21:56:20 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: wollman@khavrinen.lcs.mit.edu (Garrett Wollman) Cc: eivind@yes.no, wollman@khavrinen.lcs.mit.edu, current@FreeBSD.ORG 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/ Message-ID: <199805162156.OAA13331@usr02.primenet.com> In-Reply-To: <199805161751.NAA09343@khavrinen.lcs.mit.edu> from "Garrett Wollman" at May 16, 98 01:51:48 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199805162156.OAA13331>