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.
reply other threads:[~2011-01-25 16:04 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox