Re: DragonFly faster than linux or FreeBSD?

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

: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.
:
:Rahul

    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.

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>