From owner-freebsd-hackers Thu Feb 6 12:18:09 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA01944 for hackers-outgoing; Thu, 6 Feb 1997 12:18:09 -0800 (PST) Received: from sendero.i-connect.net ([206.190.144.100]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA01887; Thu, 6 Feb 1997 12:17:56 -0800 (PST) Received: (from shimon@localhost) by sendero.i-connect.net (8.8.5/8.8.4) id NAA09327; Thu, 6 Feb 1997 13:17:01 -0800 (PST) Message-ID: X-Mailer: XFMail 1.1-alpha [p0] on FreeBSD Content-Type: text/plain; charset=iso-8859-8 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199702060533.VAA00624@narnia.plutotech.com> Date: Thu, 06 Feb 1997 10:35:32 -0800 (PST) Organization: iConnect Corp. From: Simon Shapiro To: "Justin T. Gibbs" Subject: Re: Contigious (spelling?) allocation in kernel Cc: freebsd-hackers@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi Justin T. Gibbs; On 06-Feb-97 you wrote: ... > You really think you're going to ever transfer a full 32MB of data in a single > transaction? Even if you were, you'd have to do something special to the > kernel since it currently only generates requests of at most 64k (its a silly > restriction and it should die a horrible death). I agree. It does funny things to tape drives, CD writers, etc. > Assuming you did have a way > to stuff 32MB through all of the layers, you'd probably be better off chopping > that I/O into smaller chunks so as to reduce the amount of SG space you must > allocate. At anything over 8k, the transaction overhead starts to become an > increasingly small percentage of your I/O time, so dropping even down as low as > 1MB per transaction may better utilize your resources. Agree. The board vendor would like to see these large transfers. But a 1MB limit is not unreasonable. ... > You don't want to continuously malloc your SG list. This will kill your > performance. If it is acceptable for the system to run with all 256 > requests active at once, you have to be able to deal with all of the requests > being allocated anyway, so you might as well pool them. I agree. We never thought to dynamically allocate them, per request. What I have done is to allocate them, in blocks, into a free list, every time the free list is empty. I do not have a mechanism to ever free them, but that can be added later by comparing the current freelist size with a usage high water mark. All this brings me to another question. How can I create another kernel thread? What I am trying to do is have several execution threads in the kernel, each responsible for a given task. All I see in the drivers I read so far is a single thread, associated wit hthe calling user process. Another thread is invoked by the interrupt handler. I want a couple more. One ugly way to do it is to have a ``daemon'' which makes a known system call (ioctl) which is never returned. Aside from being ugly, it has a problem at boot time; The daemon is not there until way after init has started. What I am after is something that could resemble the swapper. Linux has few of them and they become very handy. Especially on an SMP machine. Thanx, Simon