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: link
Be 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.