Date: Thu, 06 Feb 1997 18:34:44 -0800 (PST) From: Simon Shapiro <Shimon@i-Connect.Net> To: "Justin T. Gibbs" <gibbs@narnia.plutotech.com> Cc: freebsd-scsi@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG, "Justin T. Gibbs" <gibbs@plutotech.com> Subject: Re: Contigious (spelling?) allocation in kernel Message-ID: <XFMail.970206203440.Shimon@i-Connect.Net> In-Reply-To: <199702062036.MAA01871@narnia.plutotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Justin T. Gibbs; On 06-Feb-97 you wrote: ... > Okay, so if you can live with 2MB or less per transaction, you'll have at most > a page worth of SG list per transaction, and you can use regular malloc to pool > them as you like. The aic7xxx driver does this for its SG list already, > allocating a page worth of SG lists each time. I used to have the SG list > maxed out at 256 (the limit of these controllers), but recently dropped it > down to 32 until the 64k limit goes away (17 would be sufficient for anything > that the kernel does, but I wanted it to be a power of 2 for efficient pooling). I have noticed that. This driver (aic7xxx) has been very helpful in writing this beast. I have pretty much adopted most of what you say. Except that we pre-allocate an SG list for every CCB. It works better for this HBA, even if it costs more in memory. I allow the size of the list to be tunable. Which brings me to the next question :-)) How do i pass parameters to a driver at boot time? Similar to the Linux lilo/insmod stuff. ... > You have a couple choices. One is to make another in-kernel process like > the page daemon. Another is to add software interrupt handlers for your > tasks. This can work well if your workload has clean interdependencies. > For example, the CAM SCSI code will add another software interrupt handler that > deals with work provided by the controller's interrupt routine at a lower > priority then the hardware interrupts themselves. This ensures that your > controller interrupt handler is as short as possible (they curently call up > into the mid layer at raised SPL blocking other interrupts) as the current > scheme can be really nasty if you are sharing an interrupt with a device that > requires fast response times (like a Fibre Channel or ethernet card). This is EXACTLY what I am after! For the same reasons. The DPT can handle a cache hit in less than a microsecond. I want to be able to get out of the interrupt routine as fast as possible, and hand the rest of the processing to some other thread. How do I do that? Looks to me as if the software interrupt route is the simplest/best, but what are the semantics for its calling, etc. ? Thanx! Hope I could return these favors one day... Simon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.970206203440.Shimon>