Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 30 Oct 1997 23:06:45 -0500 (EST)
From:      Chuck Robey <chuckr@glue.umd.edu>
To:        "Jamil J. Weatherbee" <jamil@trojanhorse.ml.org>
Cc:        hackers@FreeBSD.ORG
Subject:   Re: Kernel Preemption
Message-ID:  <Pine.BSF.3.96.971030230554.10708A-100000@picnic.mat.net>
In-Reply-To: <Pine.BSF.3.96.971030202542.275A-100000@trojanhorse.ml.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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!
----------------------------+-----------------------------------------------







Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.971030230554.10708A-100000>