From owner-freebsd-hackers Thu Oct 30 21:09:11 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA11403 for hackers-outgoing; Thu, 30 Oct 1997 21:09:11 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from picnic.mat.net (picnic.mat.net [206.246.122.117]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA11376 for ; Thu, 30 Oct 1997 21:09:00 -0800 (PST) (envelope-from chuckr@glue.umd.edu) Received: from localhost (chuckr@localhost) by picnic.mat.net (8.8.7/8.8.5) with SMTP id XAA10748; Thu, 30 Oct 1997 23:06:46 -0500 (EST) X-Authentication-Warning: picnic.mat.net: chuckr owned process doing -bs Date: Thu, 30 Oct 1997 23:06:45 -0500 (EST) From: Chuck Robey X-Sender: chuckr@picnic.mat.net To: "Jamil J. Weatherbee" cc: hackers@FreeBSD.ORG Subject: Re: Kernel Preemption In-Reply-To: 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 On Thu, 30 Oct 1997, Jamil J. Weatherbee wrote: > > 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 Can't you just use nice(1) to raise the priority of maplay? > > 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? > > > > > > > ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@glue.umd.edu | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run Journey2 and picnic, both FreeBSD (301) 220-2114 | version 3.0 current -- and great FUN! ----------------------------+-----------------------------------------------