From owner-freebsd-hackers Thu Oct 30 20:36:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA09708 for hackers-outgoing; Thu, 30 Oct 1997 20:36:08 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from trojanhorse.ml.org (mdean.vip.best.com [206.86.94.101]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA09703 for ; Thu, 30 Oct 1997 20:36:03 -0800 (PST) (envelope-from jamil@trojanhorse.ml.org) Received: from localhost (jamil@localhost) by trojanhorse.ml.org (8.8.7/8.8.5) with SMTP id UAA00305 for ; Thu, 30 Oct 1997 20:35:56 -0800 (PST) Date: Thu, 30 Oct 1997 20:35:55 -0800 (PST) From: "Jamil J. Weatherbee" To: hackers@freebsd.org Subject: Kernel Preemption Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk What is being done in the area of making the kernel preemptable. I had some issues recently because of the size of blocks that some drivers can read/write and the length of time it might take them could be prehibitive, for instance something that just outb()'s a block, which i have discovered can e as big as a 1/2 megabyte. So in general if this is a long time you have a problem with interactive response. For instance using rtprio 20 maplay x.mp3 to run an mpeg3 file which consumes about 40% cpu time for me usually runs quite nicely (no popping etc). With the exception of a very rare pop under heavy disk load, such as a find on the whole drive. In fact I often do make worlds and run mpeg 3's without a glitch. This should also apply to those interested in burning cd roms. A regualr user can log on while youre doing these things and ruin your whole day via: cat /dev/urandom > /dev/null Now you have a real problem with running any "realtime" processes. What steps can be taken in the freebsd kernel to remedy this sort of thing. I am not saying that urandom should not be in the kernel, just that a better method is needed of doing cpu or time intensive tasks in the kernel. We cannot always depend on ever read/write operation being instantaneous, even if our driver is the most holy of holy interrupt driven stuff. There is no good reason you shouldn't be able to do an intensive calculation in the kernel. Would whatever SMP stuff is being worked on apply here, even without multiple processors?