Date: Thu, 30 Oct 1997 20:35:55 -0800 (PST) From: "Jamil J. Weatherbee" <jamil@trojanhorse.ml.org> To: hackers@freebsd.org Subject: Kernel Preemption Message-ID: <Pine.BSF.3.96.971030202542.275A-100000@trojanhorse.ml.org>
next in thread | raw e-mail | index | archive | help
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?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.971030202542.275A-100000>