Re: [Qemu-devel] [Bug 899140] Re: Problem with Linux Kernel Traffic Control

[Stefan Hajnoczi]

On Sun, Dec 04, 2011 at 03:54:12PM -0000, Vincent Autefage wrote:
> The result without TC is about 120 Mbit/s.
> I check the bandwidth with lot of programs (not only with Iperf) and the 
> result is also the same....
> 
> However, if I use the same raw image and the same TC configuration with 
> the version 0.14.0 of QEMU or with some real physical hosts, the result 
> with TC is about 19.2 Mbit/s what is the desired result...

Thanks for checking if tc is involved in this bug.

Git bisect can identify which commit introduced the bug between QEMU
0.14.0 and 0.14.1.  The following steps show how to do this:

Clone the QEMU git repository:
$ git clone git://git.qemu.org/qemu.git
$ cd qemu

Double-check that 0.14.1 has the bug:
$ git checkout v0.14.1
$ make distclean
$ ./configure --target-list=x86_64-softmmu
$ make
$ # test x86_64-softmmu/qemu-system-x86_64 binary

Double-check that 0.14.0 does *not* have the bug:
$ git checkout v0.14.0
$ make distclean
$ ./configure --target-list=x86_64-softmmu
$ make
$ # test x86_64-softmmu/qemu-system-x86_64 binary

Now you can be confident that 0.14.0 and 0.14.1 do indeed behave
differently when built from source.  It's time to perform the bisect,
you can read more about what this does in the git-bisect(1) man page.

Find the commit that introduced the bug:
$ git bisect start v0.14.1 0.14.0
$ make distclean
$ ./configure --target-list=x86_64-softmmu
$ make
$ # test x86_64-softmmu/qemu-system-x86_64 binary

If tc achieves ~20 Mbit/s:
$ git bisect good

Otherwise:
$ git bisect bad

Git bisect will keep splitting the commit history in half until it
reaches the point where QEMU's behavior changes from good to bad.  So
you typically need to build and test a couple of times until the guilty
commit has been identified.

Stefan