Il 20/11/2013 12:00, Luigi Rizzo ha scritto: > > WITHOUT THE PATCH, booting becomes slow as soon as the timer tick starts > and we load dummynet (which also starts a kernel thread every > millisecond). > You should be able to see how the printing of kernel messages slows down > terribly around this point: > > ... > Timecounters tick every 1.000 msec > ipfw2 initialized, divert loadable, nat loadable, default to accept, > logging disabled > DUMMYNET 0 with IPv6 initialized (100409) > .... > > and then it takes a long/varible time to reach the login prompt, > easily a couple of minutes or more. > If you start pkt-gen now, you should see a much lower rate, > around 300-500Kpps > > > > Since the problem seems timer-related, it makes sense that you are > not seeing much difference in linux which is probably tickless, > and that the trouble comes out on FreeBSD after the timers are > initialized.
Saw it now with your FreeBSD guest. > But again I have no idea if my patch (which simply reverts part of > the offending commit) makes sense. No, the patch is wrong. :( Before Alex's patch, setting a timer did a timer_settime system call. After, setting the timer exits QEMU's event loop (which uses poll) and reenters it with a new deadline. This wouldn't be a problem; the difference is between one system call (timer_settime and a signal delivery (SIGALRM) before the patch, and two system calls afterwards (write to a pipe or eventfd + calling poll again when re-entering the event loop). Unfortunately, the exit/enter causes the main loop to grab the iothread lock, which in turns kicks the VCPU thread out of execution. The problem happens with "-smp 2" because FreeBSD uses a "pause" instruction in its idle loop, and QEMU does not implement it. Thus a lot of time is wasted running the second, idle VCPU rather than the first. The fix could be to implement the pause instruction. Paolo Paolo
