DragonFly kernel List (threaded) for 2004-06
Re: DragonFly faster than linux or FreeBSD?
:It seems to me also that KDE starts up faster on DragonFly than on
:Linux, on the same laptop. But it's just a subjective impression.
:However, anything involving heavy disk-writing activity -- untarring a
:large tarball, for example -- slows down DragonFly a lot. (I think
:this happened with FreeBSD 4 too, but my subjective impression is it's
:worse with DragonFly, even though I ran FreeBSD 4 on an older and much
:slower laptop.) Basically, when doing a lot of disk writing, audio
:playback skips a lot, sometimes the mouse pointer or keyboard typing
:lock up briefly, or clicking on an icon (even something simple and
:quick like an xterm) has a very delayed effect, and so on. Linux
:seems to behave much more smoothly. I never get audio skips unless
:some runaway program is eating memory and the system is swapping a
:lot. It may be due to the preemptible kernel, but that should then
:slow down an untarring process, and I don't notice a remarkable
:slowdown there either.
All of this actually makes quite a bit of sense. KDE startup time
is heavily dependant on efficiencies and optimizations in the VM
system because it generates a lot of page faults (copy on write and
zero-fill mainly). All the BSD's have always done a very good job
handling program startup.
Heavy I/O activity should only really have a 'glitch' effect in regards
to processes competing for disk I/O. Other possibilities include overheads
that occur if (e.g.) your IDE drive is not operating in a DMA mode.
You can query the DMA modes with 'atacontrol'. e.g. on my AMD-XP box:
dhcp60# atacontrol mode 0
Master = UDMA133 <<< this is my HD
Slave = ???
dhcp60# atacontrol mode 1
Master = PIO4 <<<< CDROM
Slave = PIO1 <<<< CF READER
If the HD is running in a PIO mode the cpu overhead for I/O is always
going to be pretty bad.
That said, however, I will say that I have noticed plenty of mouse
glitching and terminal-opening delays on my workstation, so I know that
there is definitely an issue somewhere. It could be a glitch in the
scheduler's priority handling.
Note that interrupt threads are preemptive under DFly, so it isn't an
issue related to kernel preemption per-say. Userland can always be
preempted by the scheduler so I suspect it is more of an issue with the
scheduler not degrading the dynamic priority of the 'tar' process enough.