Re: [9fans] I/O load crashes Qemu - Plan9

This is a discussion on Re: [9fans] I/O load crashes Qemu - Plan9 ; > On a T42 running FreeBSD, a stock FreeBSD-4.11/qemu gets > 18MB/s & plan9/qemu gets 3MB/s. Both tested by writing 100MB > from /dev/zero to a file. Neither needs any special drivers. > > I think part of the performance ...

+ Reply to Thread
Results 1 to 8 of 8

Thread: Re: [9fans] I/O load crashes Qemu

  1. Re: [9fans] I/O load crashes Qemu

    > On a T42 running FreeBSD, a stock FreeBSD-4.11/qemu gets
    > 18MB/s & plan9/qemu gets 3MB/s. Both tested by writing 100MB
    > from /dev/zero to a file. Neither needs any special drivers.
    >
    > I think part of the performance problem is qemu emulates an
    > early Intel ATA controller chip (PIIX3) and perhaps plan9
    > does not do certain optimizations. It would not be too hard
    > to emulate a more modern controller.


    try turning dma on. it is very unlikely that plan 9 is missing some
    important ata optimization.

    > IMHO a virtualizable processor is the necessary first step as
    > it clears one's mind about what not to do in an efficient
    > virtualizable IO architecture!


    unless you are contemplating a processor with i/o instructions,
    what does the processor have to do with i/o architecture?

    > Emulating grotty device
    > registers with horrible side-effects is just too painful and
    > one would be forced to abstract that out. Probably too late
    > for that!


    i find there's a certain simplicty in dealing directly
    with hardware, provided one has documentation.

    but just wait, there will come a day when people complain
    about the nasty registers in vm and how it would be good to
    abstract that stuff out.

    i think that may have been yesterday.

    - erik



  2. Re: [9fans] I/O load crashes Qemu

    On Fri, 13 Jun 2008 20:39:48 EDT erik quanstrom wrote:
    > > On a T42 running FreeBSD, a stock FreeBSD-4.11/qemu gets
    > > 18MB/s & plan9/qemu gets 3MB/s. Both tested by writing 100MB
    > > from /dev/zero to a file. Neither needs any special drivers.
    > >
    > > I think part of the performance problem is qemu emulates an
    > > early Intel ATA controller chip (PIIX3) and perhaps plan9
    > > does not do certain optimizations. It would not be too hard
    > > to emulate a more modern controller.

    >
    > try turning dma on. it is very unlikely that plan 9 is missing some
    > important ata optimization.


    Already tried. echo 'dma on' > /dev/sdC0/ctl doesn't make
    any difference in performance.

    > > IMHO a virtualizable processor is the necessary first step as
    > > it clears one's mind about what not to do in an efficient
    > > virtualizable IO architecture!

    >
    > unless you are contemplating a processor with i/o instructions,
    > what does the processor have to do with i/o architecture?


    Just that if you have no incentive to virtualize IO, you are
    unlikely to think about making it efficient.

    > i find there's a certain simplicty in dealing directly
    > with hardware, provided one has documentation.


    Provided it is complete and the h/w well designed and
    interface regular. Unfortunately not all that common.

    > but just wait, there will come a day when people complain
    > about the nasty registers in vm and how it would be good to
    > abstract that stuff out.


    Ha! First we have to get there.


  3. Re: [9fans] I/O load crashes Qemu

    I don't know how the praise of "excellent" was bestowed on QEMU. It
    may work well on a x86 emulating an x86 but try something else. It
    ends in tears.

    brucee


  4. Re: [9fans] I/O load crashes Qemu

    On Sat, Jun 14, 2008 at 1:58 AM, Bruce Ellis wrote:
    > I don't know how the praise of "excellent" was bestowed on QEMU. It
    > may work well on a x86 emulating an x86 but try something else. It
    > ends in tears.
    >


    just like opening up an x86 machine and trying to stick a mips
    processor inside. at the end of the day you get qemu-mips.

    iru


  5. Re: [9fans] I/O load crashes Qemu

    > I don't know how the praise of "excellent" was bestowed on QEMU. It
    > may work well on a x86 emulating an x86 but try something else. It
    > ends in tears.
    >


    this isn't a defense of qemu. i don't know enough about it
    to defend it.

    however, why is it a requirement that a vm be able to emulate
    other machines?

    - erik


  6. Re: [9fans] I/O load crashes Qemu

    >> i find there's a certain simplicty in dealing directly
    >> with hardware, provided one has documentation.

    >
    > Provided it is complete and the h/w well designed and
    > interface regular. Unfortunately not all that common.


    you continue with this claim without presenting evidence.

    i respond to this because i think there is a prevalent
    attitude, not well-informed by experience, that hardware
    is bad and impossible to program. my opinion, based on
    experience, is this is not true. and restating the untruth
    has the consequence of discouraging folk from working
    on drivers, thus reenforcing the myth.

    were it true, it would not be an attitude condusive
    to getting things done. hardware, unlike linux, is
    unavoidable.

    to your claim:

    in my experience, the complexity of the hardware has very
    little to do with the complexity of the driver.

    for example, the intel 82598 10gbe is a beast of a part.
    341 pages of documentation. 200 registers. yet it's a
    simple driver because
    1. of experience with other ethernet drivers;
    2. everything the driver needs from the kernel already exists;
    3. most complicated functionality was ignored;
    4. the spec has not changed; and
    5. only one part implements the register set.

    - erik



  7. Re: [9fans] I/O load crashes Qemu

    On Sat, Jun 14, 2008 at 9:53 AM, erik quanstrom wrote:
    >> I don't know how the praise of "excellent" was bestowed on QEMU. It
    >> may work well on a x86 emulating an x86 but try something else. It
    >> ends in tears.
    >>

    >
    > this isn't a defense of qemu. i don't know enough about it
    > to defend it.
    >
    > however, why is it a requirement that a vm be able to emulate
    > other machines?
    >


    because it claims to do so?

    iru


  8. Re: [9fans] I/O load crashes Qemu

    > >> i find there's a certain simplicty in dealing directly
    > >> with hardware, provided one has documentation.

    > >
    > > Provided it is complete and the h/w well designed and
    > > interface regular. Unfortunately not all that common.

    >
    > you continue with this claim without presenting evidence.

    ...
    > for example, the intel 82598 10gbe is a beast of a part.
    > 341 pages of documentation. 200 registers. yet it's a
    > simple driver because

    ...
    > 3. most complicated functionality was ignored;


    I rest my case :-)

    How much simpler it would've been if instead of 200 registers
    there was just a fifo in each direction.
    You can do everything you want with a small set of commands.
    An open ended interface that can be efficiently virtualized.

    Or why not just implement something like 9p?

    > i respond to this because i think there is a prevalent
    > attitude, not well-informed by experience, that hardware
    > is bad and impossible to program. my opinion, based on
    > experience, is this is not true. and restating the untruth
    > has the consequence of discouraging folk from working
    > on drivers, thus reenforcing the myth.


    Sorry, my experience does not match yours. May be things have
    improved since I used to write drivers but controllers like
    NEC765 were pretty bad (I can cite a lot of other examples
    but I won't, not here!).

    As a driver writer one should go in with eyes open so nothing
    grosses you out, read specs thoroughly but when in doubt
    experiment and so on.

    > were it true, it would not be an attitude condusive
    > to getting things done.


    If only. Unfortunately too much bad hardware gets drivers
    written for them.

    This is so far from qemu or plan9 that I will stop now.


+ Reply to Thread