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

This is a discussion on [9fans] I/O load crashes Qemu - Plan9 ; Hi, I currently use Plan 9 in qemu 0.9.1; whenever I try to do anything I/O demanding such as unpacking a ~100MB tarball, qemu locks up and refuses further connections (via vnc, or gdb for example). I am using fossil ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 23

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

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

    Hi,

    I currently use Plan 9 in qemu 0.9.1; whenever I try to do anything I/O
    demanding such as unpacking a ~100MB tarball, qemu locks up and refuses
    further connections (via vnc, or gdb for example). I am using fossil
    alone. This behavior occurs whether kqemu is enabled or not, though it
    happens a lot faster w/o kqemu.

    Has anyone else noticed anything like this? Any thoughts about running
    Plan 9 in qemu?

    Thanks,
    --vs


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

    On Jun 12, 2008, at 9:54 PM, Venkatesh Srinivas wrote:

    > Hi,
    >
    > I currently use Plan 9 in qemu 0.9.1; whenever I try to do anything
    > I/O
    > demanding such as unpacking a ~100MB tarball, qemu locks up and
    > refuses
    > further connections (via vnc, or gdb for example). I am using fossil
    > alone. This behavior occurs whether kqemu is enabled or not, though it
    > happens a lot faster w/o kqemu.
    >
    > Has anyone else noticed anything like this? Any thoughts about running
    > Plan 9 in qemu?
    >
    > Thanks,
    > --vs
    >


    Compressed disc image (qcow2)? That's what screwed up my fossil+venti.



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

    Thoughts:
    + Running Plan 9 on qemu is slow (when doing disk access) (the
    ethernal DMA wiwi bla bla bla)
    + qcow2 is quality challenged, but I think that the standard plan9.img
    ain't qcow2
    +kqemu has worked for me very well... but I have not benchmarked it.
    + Unpacking 100 MiB sounds like a lot of I/O... Ergo a lot of "disk"
    ergo a lot of no-dma bottleneck

    Good luck

    On 6/12/08, Pietro Gagliardi wrote:
    > On Jun 12, 2008, at 9:54 PM, Venkatesh Srinivas wrote:
    >
    >
    > > Hi,
    > >
    > > I currently use Plan 9 in qemu 0.9.1; whenever I try to do anything I/O
    > > demanding such as unpacking a ~100MB tarball, qemu locks up and refuses
    > > further connections (via vnc, or gdb for example). I am using fossil
    > > alone. This behavior occurs whether kqemu is enabled or not, though it
    > > happens a lot faster w/o kqemu.
    > >
    > > Has anyone else noticed anything like this? Any thoughts about running
    > > Plan 9 in qemu?
    > >
    > > Thanks,
    > > --vs
    > >
    > >

    >
    > Compressed disc image (qcow2)? That's what screwed up my fossil+venti.
    >
    >
    >



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

    I've tried with both qcow2 and raw; raw takes longer to get to a crash,
    but still reliably crashes. Strangely, connecting to qemu with gdb
    before Plan 9 starts reduces the crash rate a lot, but it might just be
    because the world is noticeably slower...

    --vs


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

    On Fri, Jun 13, 2008 at 12:00 PM, Venkatesh Srinivas wrote:
    > I've tried with both qcow2 and raw; raw takes longer to get to a crash,
    > but still reliably crashes. Strangely, connecting to qemu with gdb
    > before Plan 9 starts reduces the crash rate a lot, but it might just be
    > because the world is noticeably slower...


    Does it actually crash or just hang? Maybe you just need to wait for
    the I/O to drop before it will accept connections again?
    -sqweek


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

    Everything, in my experience, crashes QEMU. Nice try.

    Just the opinion of me and my dog (who barks loudly when I shout
    f**king QEMU - piece of f**king sh*t!).

    Hey, this is off topic but ... anyone had fun with a Asus EeePC? The
    excess stock are being sold in Oz and I got a 4G for US$300. Tho Amzon
    were down to 4. Let me know off-list.

    Regards,

    The Dude With The Little Dog.


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


    I have problems with Qemu too. Qemu hangs booting, hangs after booting,
    hangs ramdomly, ... with or without venti.

    I am using now a "new" PC for Plan9

    > Everything, in my experience, crashes QEMU. Nice try.
    >
    > Just the opinion of me and my dog (who barks loudly when I shout
    > f**king QEMU - piece of f**king sh*t!).
    >
    > Hey, this is off topic but ... anyone had fun with a Asus EeePC? The
    > excess stock are being sold in Oz and I got a 4G for US$300. Tho Amzon
    > were down to 4. Let me know off-list.
    >
    > Regards,
    >
    > The Dude With The Little Dog.
    >
    >



    --
    Rodolfo García AKA kix
    http://www.kix.es/
    EA4ERH (@IN80ER)



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

    On Thu, Jun 12, 2008 at 9:54 PM, Venkatesh Srinivas wrote:
    > Hi,
    >
    > I currently use Plan 9 in qemu 0.9.1; whenever I try to do anything I/O
    > demanding such as unpacking a ~100MB tarball, qemu locks up and refuses
    > further connections (via vnc, or gdb for example). I am using fossil
    > alone. This behavior occurs whether kqemu is enabled or not, though it
    > happens a lot faster w/o kqemu.
    >
    > Has anyone else noticed anything like this? Any thoughts about running
    > Plan 9 in qemu?


    Yes, I had this problem several times while doing replica/pull
    yesterday. Qemu uses up all cpu load, and does not respond. Sometimes
    it comes back on from the lock up, while other times I lose my
    patience and kill it. I went back to 0.9.0. Lets see if I have the
    same problem.

    fhs


  9. Re: I/O load crashes Qemu

    I am experiencing crashes here too. QEMU 0.9.1 with and without
    kqemu, using qcow2, on Linux 2.6.24. I have built QEMU from source so
    I can backtrace it next time it happens.

    Perhaps Plan 9 under lguest is the way to go.

    Stefan

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

    > Everything, in my experience, crashes QEMU. Nice try.

    > Just the opinion of me and my dog (who barks loudly when I shout
    > f**king QEMU - piece of f**king sh*t!).


    I have used qemu/freebsd for the past 4 years or so. On the
    whole it has worked quite well. I often use plan9, Windows
    2000 and freebsd under qemu for hours on end. Juergen Lock
    has done an excellent job on making sure qemu+kqemu continue
    to work on freebsd but he has needed feedback from
    qemu/freebsd users.

    If you plan on continuing with qemu it might be worth asking
    on the qemu-devel mailing list or #qemu on freenode as I
    don't think any qemu dveloper follows 9fans. But they will
    need details like the host OS and version, qemu version,
    command line used, exact symptoms, steps to repeat the
    problem etc.


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

    In fact it is definetly not a plan9 issue...
    If qemu fails hosting plan 9, it affects plan 9 but there is little to
    be done unless we communicate with the qemu dev team.

    Plan 9 is not the only os having problems with DMA access through
    qemu. I am myself a moron... All I know is that the issue exists, I
    don't know why... (But it would be very appreciated if an explanation
    is given)

    One thing I've thought several times is that perhaps qemu-ide specific
    drivers need to be done. Many hosted OSs need custom made drivers to
    be used with a virtualizer.

    I am sure a lot has been discused about this on the list.
    I'll try to do a quick scan about it later.


    On 6/13/08, Bakul Shah wrote:
    > > Everything, in my experience, crashes QEMU. Nice try.

    >
    > > Just the opinion of me and my dog (who barks loudly when I shout
    > > f**king QEMU - piece of f**king sh*t!).

    >
    >
    > I have used qemu/freebsd for the past 4 years or so. On the
    > whole it has worked quite well. I often use plan9, Windows
    > 2000 and freebsd under qemu for hours on end. Juergen Lock
    > has done an excellent job on making sure qemu+kqemu continue
    > to work on freebsd but he has needed feedback from
    > qemu/freebsd users.
    >
    > If you plan on continuing with qemu it might be worth asking
    > on the qemu-devel mailing list or #qemu on freenode as I
    > don't think any qemu dveloper follows 9fans. But they will
    > need details like the host OS and version, qemu version,
    > command line used, exact symptoms, steps to repeat the
    > problem etc.
    >
    >



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

    >perhaps qemu-ide specific drivers need to be done.
    > Many hosted OSs need custom made drivers to
    > be used with a virtualizer.


    i must say that my experience with VM/370 was otherwise,
    for the standard devices. there were extensions you could access
    if you liked, but the basic emulation was solid. the only restriction i remember
    was that you couldn't any longer dynamically modify channel programs
    (by having a channel program read some blocks into memory that would
    later be executed in the same channel program), but other systems
    imposed a similar restriction on that hardware.

    the peculiar thing about the modern virtualisers/hypervisors etc is that
    they require specialised drivers but are no easier (often harder) to drive than
    actual hardware! it's all gone wrong!



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

    > the peculiar thing about the modern virtualisers/hypervisors etc is that

    sorry. i meant to write "one peculiar thing ...", because there are others.



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

    > the peculiar thing about the modern virtualisers/hypervisors etc is that
    > they require specialised drivers but are no easier (often harder) to drive than
    > actual hardware! it's all gone wrong!


    but the blinding performance is ... check that.

    - erik



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

    Any good recommended lecture to learn about good virtualization?

    I imagine that the biggest issue is to avoid a racing condition
    between the two(or 'n') running kernels.

    Then... Would it be very hard to build an fs that allows to share real
    hardware with another kernel running alongside plan 9? I imagine that
    the so called hypervisors are kind of a "(exo-)scheduler"

    A not very educated guess...

    On 6/13/08, erik quanstrom wrote:
    > > the peculiar thing about the modern virtualisers/hypervisors etc is that
    > > they require specialised drivers but are no easier (often harder) to drive than
    > > actual hardware! it's all gone wrong!

    >
    >
    > but the blinding performance is ... check that.
    >
    >
    > - erik
    >
    >
    >



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

    On Fri, 13 Jun 2008 21:33:15 BST Charles Forsyth wrote:
    > >perhaps qemu-ide specific drivers need to be done.
    > > Many hosted OSs need custom made drivers to
    > > be used with a virtualizer.


    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.

    > i must say that my experience with VM/370 was otherwise,
    > for the standard devices. there were extensions you could access
    > if you liked, but the basic emulation was solid. the only restriction i reme
    > mber
    > was that you couldn't any longer dynamically modify channel programs
    > (by having a channel program read some blocks into memory that would
    > later be executed in the same channel program), but other systems
    > imposed a similar restriction on that hardware.
    >
    > the peculiar thing about the modern virtualisers/hypervisors etc is that
    > they require specialised drivers but are no easier (often harder) to drive th
    > an
    > actual hardware! it's all gone wrong!


    I don't think you can escape writing device emulation code
    for the virtualization layer (when the guest os diddles a
    device register, someone has to implement its semantics).
    If the emulated device is not the same as some real device,
    the guest os has to have a special drivers for it.

    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! 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!


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

    On Jun 13, 2008, at 7:01 PM, Bakul Shah wrote:

    > IMHO a virtualizable processor is the necessary first step as



    And don't forget the cost of a virtualizer v. the cost of actual
    hardware. Verilog is free, but the device to make it is not. Start
    simple:

    void
    main(int, char *[])
    {
    while(readbyte()){
    parseinst();
    doinst();
    }
    exits(nerrs ? "error" : 0);
    }




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

    On Fri, 13 Jun 2008 19:26:42 EDT Pietro Gagliardi wrote:
    > On Jun 13, 2008, at 7:01 PM, Bakul Shah wrote:
    >
    > > IMHO a virtualizable processor is the necessary first step as

    >
    >
    > And don't forget the cost of a virtualizer v. the cost of actual
    > hardware. Verilog is free, but the device to make it is not. Start
    > simple:
    >
    > void
    > main(int, char *[])
    > {
    > while(readbyte()){
    > parseinst();
    > doinst();
    > }
    > exits(nerrs ? "error" : 0);
    > }


    ?

    You don't need this sort of code in a virtualizable processor.
    See for example
    http://en.wikipedia.org/wiki/Popek_a...n_requirements


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

    FPGA's are getting cheaper. A friend of mine got a nice Spartan III
    for less than us$50

    Clock speeds are still behind the usual ASIC (lack of sleep might
    alter my grammar habilities), but I think they are ok for things like
    a java vm, or a nes emulator...

    Years ago I made a picoJava based processor and it was really fun...
    All we need is to put that into a PCI thing and enjoy (And it would
    even be better if you can program the thing dynamically from your pc
    as needed)

    I also believe I've seen some SUN workstations that do have a "pci"
    processor to emulate an x86 machine...

    Blah... I really need to sleeep.
    I hate PHP.

    On 6/13/08, Pietro Gagliardi wrote:
    > On Jun 13, 2008, at 7:01 PM, Bakul Shah wrote:
    >
    >
    > > IMHO a virtualizable processor is the necessary first step as
    > >

    >
    >
    > And don't forget the cost of a virtualizer v. the cost of actual hardware.
    > Verilog is free, but the device to make it is not. Start simple:
    >
    > void
    > main(int, char *[])
    > {
    > while(readbyte()){
    > parseinst();
    > doinst();
    > }
    > exits(nerrs ? "error" : 0);
    > }
    >
    >
    >
    >



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

    On Sat, Jun 14, 2008 at 1:42 AM, Lorenzo Fernando Bivens de la Fuente
    > FPGA's are getting cheaper. A friend of mine got a nice Spartan III
    > for less than us$50
    >
    > Clock speeds are still behind the usual ASIC (lack of sleep might
    > alter my grammar habilities), but I think they are ok for things like
    > a java vm, or a nes emulator...


    Ever heard of 'Dis on a Chip'? http://groups.google.com/group/dis-on-a-chip

    uriel


+ Reply to Thread
Page 1 of 2 1 2 LastLast