From: Jes Sorensen <Jes.Sorensen@redhat.com> To: QEMU Developers <qemu-devel@nongnu.org>, KVM General <kvm@vger.kernel.org> Cc: Chris Wright <chrisw@redhat.com> Subject: QEMU/KVM Call notes for Jan 25, 2011 Date: Tue, 25 Jan 2011 17:04:19 +0100 [thread overview] Message-ID: <4D3EF483.5090308@redhat.com> (raw) Hello, Please find attached my notes from the weekly QEMU/KVM call January 25, 2011. My apologies if I got something wrong. Jes - QEMU 0.14/0.15 releases - Feb 1st 2011 branch to stable tree for 0.14. Anthony would like to do a formal release quickly, so hopefully within 1-2 weeks after snapshot (Feb 15, 2011). - We should plan a formal release schedule for 0.15 http://wiki.qemu.org/Planning/0.15-example - coroutines - Proposal from Stefan Hajnoczi http://www.mail-archive.com/qemu-devel@nongnu.org/msg52522.html - First example is to try and calls to synchronous system calls in QCOW2 codebase. - Suggest every image format in block layer have it's own coroutine layer. - Long term, can/should we apply this to entire block layer? Q: Can we go to real threads in the block layer? A: coroutines are light weight, and we have more control, but it is an option. Going to threads would require a serious amount of work making the full QEMU stack thread safe. Doesn't solve the parallelism problem, so not the final long term solution to the scalability problem. Q: Should we do coroutines in the block layer rather than the image formats? This would provide aio support for formats that do not currently implement aio calls. A: Avi suggests mixed approach, to benefit from not having explicit synchronization points in high performance formats. Follow-on longer discussion about implementation details, which is to be followed up in email. - glib integration - Proposal from Anthony http://www.mail-archive.com/qemu-devel@nongnu.org/msg52798.html - Provides portable interfaces to threading, data structures, and utility functions. - Idea would be to get rid of a lot of duplicated code which we would get from glib instead. - Also consider gio and gobject. - gobject could be a replacement for qdev - gobject could help make vnc server become standalone - Not suggesting to convert everything to glib types (gint, guint, etc). Clarification of which types are recommended will be needed in CODING_STYLE Q: Which would be the first subsystem to convert A: Convert QEMU threads to gthreads - Comment, doing a conversion of QMP would be good, but Luiz will not have time to look at this for maybe 2 months. - Suggestion from Paolo Bonzini to make a standalone library for JSON, rather than relying on the glib implementation - Google Summer of Code 2011 - please post suggestions to the list, and we should revisit this item next week.
WARNING: multiple messages have this Message-ID (diff)
From: Jes Sorensen <Jes.Sorensen@redhat.com> To: QEMU Developers <qemu-devel@nongnu.org>, KVM General <kvm@vger.kernel.org> Cc: Chris Wright <chrisw@redhat.com> Subject: [Qemu-devel] QEMU/KVM Call notes for Jan 25, 2011 Date: Tue, 25 Jan 2011 17:04:19 +0100 [thread overview] Message-ID: <4D3EF483.5090308@redhat.com> (raw) Hello, Please find attached my notes from the weekly QEMU/KVM call January 25, 2011. My apologies if I got something wrong. Jes - QEMU 0.14/0.15 releases - Feb 1st 2011 branch to stable tree for 0.14. Anthony would like to do a formal release quickly, so hopefully within 1-2 weeks after snapshot (Feb 15, 2011). - We should plan a formal release schedule for 0.15 http://wiki.qemu.org/Planning/0.15-example - coroutines - Proposal from Stefan Hajnoczi http://www.mail-archive.com/qemu-devel@nongnu.org/msg52522.html - First example is to try and calls to synchronous system calls in QCOW2 codebase. - Suggest every image format in block layer have it's own coroutine layer. - Long term, can/should we apply this to entire block layer? Q: Can we go to real threads in the block layer? A: coroutines are light weight, and we have more control, but it is an option. Going to threads would require a serious amount of work making the full QEMU stack thread safe. Doesn't solve the parallelism problem, so not the final long term solution to the scalability problem. Q: Should we do coroutines in the block layer rather than the image formats? This would provide aio support for formats that do not currently implement aio calls. A: Avi suggests mixed approach, to benefit from not having explicit synchronization points in high performance formats. Follow-on longer discussion about implementation details, which is to be followed up in email. - glib integration - Proposal from Anthony http://www.mail-archive.com/qemu-devel@nongnu.org/msg52798.html - Provides portable interfaces to threading, data structures, and utility functions. - Idea would be to get rid of a lot of duplicated code which we would get from glib instead. - Also consider gio and gobject. - gobject could be a replacement for qdev - gobject could help make vnc server become standalone - Not suggesting to convert everything to glib types (gint, guint, etc). Clarification of which types are recommended will be needed in CODING_STYLE Q: Which would be the first subsystem to convert A: Convert QEMU threads to gthreads - Comment, doing a conversion of QMP would be good, but Luiz will not have time to look at this for maybe 2 months. - Suggestion from Paolo Bonzini to make a standalone library for JSON, rather than relying on the glib implementation - Google Summer of Code 2011 - please post suggestions to the list, and we should revisit this item next week.
next reply other threads:[~2011-01-25 16:04 UTC|newest] Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top 2011-01-25 16:04 Jes Sorensen [this message] 2011-01-25 16:04 ` [Qemu-devel] QEMU/KVM Call notes for Jan 25, 2011 Jes Sorensen
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=4D3EF483.5090308@redhat.com \ --to=jes.sorensen@redhat.com \ --cc=chrisw@redhat.com \ --cc=kvm@vger.kernel.org \ --cc=qemu-devel@nongnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.