Date: Tue, 19 May 1998 11:51:59 +0900 (JST) From: Michael Hancock <michaelh@cet.co.jp> To: Terry Lambert <tlambert@primenet.com> Cc: Garrett Wollman <wollman@khavrinen.lcs.mit.edu>, eivind@yes.no, 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: <Pine.SV4.3.95.980519112825.25892A-100000@parkplace.cet.co.jp> In-Reply-To: <199805162156.OAA13331@usr02.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 16 May 1998, Terry Lambert wrote: > > > 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. I wonder if a variation of this could be used with TSM. You would preallocate staging memory; during the hard interrupt the staging memory is filled; and then it would be committed to the TSM pool later (when?). This way you don't really need to worry about running out of the socket TSM pool, you just compete for slots until they are available. I don't know if this is better than the current scheme where I suppose you would just drop the request if maxsockets were reached. If you carefully tuned the size of the TSM pool you could have a very low-latency and high bandwidth implementation without the complications of doing the above. With careful design I guess you could make a dynamic TSM model but defining Tstable, the point where you can safely deallocate, would be a challenge. We should probably go back and read Greenwald's paper again to get a better understanding of the issues. Memory utilization didn't seem to be an issue they worried about much. Regards, Mike Hancock > 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?Pine.SV4.3.95.980519112825.25892A-100000>