From owner-freebsd-scsi Thu Feb 6 12:36:56 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA03460 for freebsd-scsi-outgoing; Thu, 6 Feb 1997 12:36:56 -0800 (PST) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA03452; Thu, 6 Feb 1997 12:36:53 -0800 (PST) Received: from narnia (localhost [127.0.0.1]) by narnia.plutotech.com (8.8.5/8.7.3) with ESMTP id MAA01871; Thu, 6 Feb 1997 12:36:53 -0800 (PST) Message-Id: <199702062036.MAA01871@narnia.plutotech.com> To: Simon Shapiro cc: "Justin T. Gibbs" , freebsd-hackers@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: Contigious (spelling?) allocation in kernel In-reply-to: Your message of "Thu, 06 Feb 1997 10:35:32 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 06 Feb 1997 12:36:53 -0800 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Agree. The board vendor would like to see these large transfers. But a 1MB >limit is not unreasonable. > 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). >All this brings me to another question. How can I create another kernel >thread? > 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). >Thanx, > >Simon > -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations ===========================================