wrap location in new line using <br>

[HTML5TV.git] / media / lpc2009-Storage_API_QEMU_KVM / hCalendar.html

diff --git a/media/lpc2009-Storage_API_QEMU_KVM/hCalendar.html b/media/lpc2009-Storage_API_QEMU_KVM/hCalendar.html
index 189a266..fc36e65 100644 (file)
--- a/media/lpc2009-Storage_API_QEMU_KVM/hCalendar.html
+++ b/media/lpc2009-Storage_API_QEMU_KVM/hCalendar.html
@@ -4,19 +4,19 @@
  <span class="summary">
        Evaluating Linux storage APIs for use in QEMU/KVM
  </span>
- <br>
+<br>
  <a class="url" href="http://linuxplumbersconf.org/ocw/proposals/38">Linux Plumbers Conference</a>,
  <span class="location">Portland, OR</span>,
  <abbr class="dtstart" title="20090923">Wednesday, September 23, 2009 from 10:30 – 10:55am</span>
  <div class="description">
 KVM is a Linux kernel module that exposes hardware virtualization support to userspace. QEMU is a full system simulator that runs as a user space process and emulates/virtualizes many types of machines including a standard PC. Together, KVM and QEMU enable Linux to act as a hypervisor.
-<br>
+<p>
 As a hypervisor, I/O performance is a weak area today in Linux. Since all I/O for guests are generated from QEMU, we are largely limited by the I/O interfaces provided by the Linux kernel to userspace. The current set of storage I/O interfaces have proven to not map well to QEMU’s requirements.
-<br>
+<p>
 This talk will cover how we are currently using the storage I/O interfaces provided by Linux. It will focus on the mechanisms to generate multiple asynchonrous, scatter/gather I/O requests to buffered and non-buffered files along with physical devices. It will also cover topics like request tagging and barriers.
-<br>
+<p>
 The goal of the talk will be to generate discussion about proposed future interfaces (syslets, acalls, etc.) and to discuss whether current interfaces like linux-aio are at all salvagable.
-<br>
+<p>
 Virtualization is perhaps one of the more demanding userspace I/O workloads available so it serves as a particularly good canary in evaluating future I/O interfaces.
  </div>
 </div>