Hello,

I apologize if this problem is off topic.  I have not determined if
this issue is specific to the Google Android project or not.


The symptoms:

When I run the android emulator which is built atop qemu, the process
enters a busy loop in which it repeatedly calls clone on linux which
returns ERESTARTNOINTR.

Interspersed between each clone call were many SIGALRMs.

This was all determined using strace.


The hypothesis:

After googling a bit, I believe my symptoms are explained within this post:
http://kerneltrap.org/mailarchive/linux-kernel/2007/4/28/83322

-namely, SIGALRM interrupts a clone call, and the clone operation is
aborted.  Because the SIGALRM frequency is much greater than the
frequency of calls to clone, it does not complete for an arbitrarily
long time.


The fix:

If this hypothesis is correct, the best fix is probably to delay
launching the timer until after clone.  I leave this as an exercise to
the reader.  (In other words, I didn't look into it deeply enough.
;-)


The test:

I tested my hypothesis by altering the SIGALRM rate set by setitimer
to make it *10 times slower* in the qemu source tree tracked inside
the Android platform project.  The diff from the Android fork is
attached.

By viewing the android revision log (stored in a git repository) it
looks like this fork was created from qemu 0.8.2.  If this issue has
already been addressed in the Qemu main trunk, or if the diff does not
match the current state, let me know so I can work with the Google
fork to follow this issue.

However, I don't believe this patch should be integrated into Qemu,
but should only serve to illustrate the issue.


The environment:

My kernel is:
$ uname -a
Linux hackbox 2.6.24-19-virtual #1 SMP Wed Jun 18 15:52:10 UTC 2008
i686 GNU/Linux

This is Ubuntu:
$ lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 8.04.2
Release:	8.04
Codename:	hardy

It is running as a vmware guest in VMWare Workstation 6.0.2 build-59824.

The vmware guest is incredibly slow.  After some tinkering I have an
unverified hunch that I had configured its memory to too large a value
and the host system was swapping the guests "physical" memory to disk.

Whatever the case, the running speed of processes on the guest was
incredibly slow.


Further information:

I've brought this issue to the attention of the Android platform team here:
http://code.google.com/p/android/issues/detail?id=138&can=1&q=qemu&colspec=ID%20Type%20Version%20Security%20Status%20Owner%20Summary


Regards,
Nathan Wilcox