* QEMU/KVM Call notes for Jan 25, 2011
@ 2011-01-25 16:04 ` Jes Sorensen
0 siblings, 0 replies; 2+ messages in thread
From: Jes Sorensen @ 2011-01-25 16:04 UTC (permalink / raw)
To: QEMU Developers, KVM General; +Cc: Chris Wright
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.
^ permalink raw reply [flat|nested] 2+ messages in thread
* [Qemu-devel] QEMU/KVM Call notes for Jan 25, 2011
@ 2011-01-25 16:04 ` Jes Sorensen
0 siblings, 0 replies; 2+ messages in thread
From: Jes Sorensen @ 2011-01-25 16:04 UTC (permalink / raw)
To: QEMU Developers, KVM General; +Cc: Chris Wright
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.
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2011-01-25 16:04 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-01-25 16:04 QEMU/KVM Call notes for Jan 25, 2011 Jes Sorensen
2011-01-25 16:04 ` [Qemu-devel] " Jes Sorensen
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.