From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LUAEj-0006Ud-GD for qemu-devel@nongnu.org; Mon, 02 Feb 2009 20:38:01 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LUAEh-0006Tr-TG for qemu-devel@nongnu.org; Mon, 02 Feb 2009 20:38:00 -0500 Received: from [199.232.76.173] (port=33783 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LUAEh-0006Tn-Jw for qemu-devel@nongnu.org; Mon, 02 Feb 2009 20:37:59 -0500 Received: from wf-out-1314.google.com ([209.85.200.169]:57999) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LUAEh-0005sc-5z for qemu-devel@nongnu.org; Mon, 02 Feb 2009 20:37:59 -0500 Received: by wf-out-1314.google.com with SMTP id 27so1984288wfd.4 for ; Mon, 02 Feb 2009 17:37:58 -0800 (PST) MIME-Version: 1.0 Date: Mon, 2 Feb 2009 17:37:58 -0800 Message-ID: <13f991410902021737o3dbccbdbk77c0dd012e15f401@mail.gmail.com> From: Nathan Content-Type: multipart/mixed; boundary=00504502c74b94b2a80461f9b867 Subject: [Qemu-devel] Poor clone/SIGALRM interaction on linux host. Reply-To: nejucomo@gmail.com, qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org --00504502c74b94b2a80461f9b867 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 --00504502c74b94b2a80461f9b867 Content-Type: text/x-diff; charset=US-ASCII; name="qemu.patch" Content-Disposition: attachment; filename="qemu.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_fqpwhbnf0 JCBnaXQgZGlmZiBnb29nbGVfcWVtdV9zdHJlYW0gaXNlY19uYXRoYW5fdGltZXJfdHdlYWsKZGlm ZiAtLWdpdCBhL3FlbXVfdGltZXJzLmMgYi9xZW11X3RpbWVycy5jCmluZGV4IDJkYzA4MDYuLmQ1 MjEzMTUgMTAwNjQ0Ci0tLSBhL3FlbXVfdGltZXJzLmMKKysrIGIvcWVtdV90aW1lcnMuYwpAQCAt MjksNiArMjksMTMgQEAgUUVNVUNsb2NrICp2bV9jbG9jazsKIC8qKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKi8KIC8qIHJlYWwgdGltZSBo b3N0IG1vbm90b25pYyB0aW1lciAqLwoKKy8qIEhhY2tlZCBieSBuYXRoYW5AaXNlY3BhcnRuZXJz LmNvbSB0byBwcmV2ZW50IGJ1c3kgc3BpbiBkdXJpbmcgY2xvbmUKKyAqIG9uIGEgc2xvdyBsaW51 eCB2bSBndWVzdDoKKyAqLworI2RlZmluZSBPUklHSU5BTF9RRU1VX1VOSVhfVVNFQyA5OTkKKyNk ZWZpbmUgVFdFQUtFRF9RRU1VX1VOSVhfVVNFQyA5OTk5CisjZGVmaW5lIFFFTVVfVU5JWF9VU0VD IFRXRUFLRURfUUVNVV9VTklYX1VTRUMKKwogLyogZGlnaXQ6IHRoZSBmb2xsb3dpbmcgdHdvIHZh cmlhYmxlcyBhcmUgdXNlZCB0byBpbXBsZW1lbnQgaGlnaC1yZXNvbHV0aW9uCiAgKiBwb2xsLWJh c2VkIGludGVycnVwdHMuIHRoZSBpZGVhIGlzIHRvIGJlIGFibGUgdG8gZ2VuZXJhdGUgYW4gZW11 bGF0ZWQKICAqIGludGVycnVwdCBldmVyeSBtaWxsaXNlY29uZCwgZXZlbiBvbiBub24tTGludXgg cGxhdGZvcm1zIHdoaWNoIGRvbid0IGhhdmUKQEAgLTkxNyw5ICs5MjQsOSBAQCBzdGF0aWMgaW50 IHVuaXhfc3RhcnRfdGltZXIoc3RydWN0IHFlbXVfYWxhcm1fdGltZXIgKnQpCgogICAgIGl0di5p dF9pbnRlcnZhbC50dl9zZWMgPSAwOwogICAgIC8qIGZvciBpMzg2IGtlcm5lbCAyLjYgdG8gZ2V0 IDEgbXMgKi8KLSAgICBpdHYuaXRfaW50ZXJ2YWwudHZfdXNlYyA9IDk5OTsKKyAgICBpdHYuaXRf aW50ZXJ2YWwudHZfdXNlYyA9IFFFTVVfVU5JWF9VU0VDOwogICAgIGl0di5pdF92YWx1ZS50dl9z ZWMgPSAwOwotICAgIGl0di5pdF92YWx1ZS50dl91c2VjID0gMTAgKiAxMDAwOworICAgIGl0di5p dF92YWx1ZS50dl91c2VjID0gMTAgKiAoUUVNVV9USU1FUl9SRUFMVElNRSArIDEpOwoKICAgICBl cnIgPSBzZXRpdGltZXIoSVRJTUVSX1JFQUwsICZpdHYsIE5VTEwpOwogICAgIGlmIChlcnIpCg== --00504502c74b94b2a80461f9b867--