Re: [Xen-devel] qemu-xen-traditional: NOCACHE or CACHE_WB to open disk images for IDE

["Xu, Dongxiao" <dongxiao.xu@xxxxxxxxx>]

I attached the original patch here, which impact the performance.

Signed-off-by: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
---
 xenstore.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/xenstore.c b/xenstore.c
index 4c483e2..ac90366 100644
--- a/xenstore.c
+++ b/xenstore.c
@@ -643,7 +643,7 @@ void xenstore_parse_domain_config(int hvm_domid)
            }
             pstrcpy(bs->filename, sizeof(bs->filename), params);
 
-            flags = BDRV_O_CACHE_WB; /* snapshot and write-back */
+            flags = BDRV_O_NOCACHE;
             is_readonly = 0;
             if (pasprintf(&buf, "%s/mode", bpath) == -1)
                 continue;
-- 
1.7.2.5

Could somebody tell me the reason why this is finally checked in with 
performance impact?

Thanks,
Dongxiao

> -----Original Message-----
> From: xen-devel-bounces@xxxxxxxxxxxxx
> [mailto:xen-devel-bounces@xxxxxxxxxxxxx] On Behalf Of Xu, Dongxiao
> Sent: Friday, August 10, 2012 1:33 PM
> To: xen-devel@xxxxxxxxxxxxx
> Cc: Zhang, Yang Z; Ian Jackson; Ian Campbell; Stefano Stabellini
> Subject: [Xen-devel] qemu-xen-traditional: NOCACHE or CACHE_WB to open
> disk images for IDE
> 
> Hi list,
> 
> Recently I was debugging L2 guest slow booting issue in nested virtualization
> environment (both L0 and L1 hypervisors are all Xen).
> To boot a L2 Linux guest (RHEL6u2), it will need to wait more than 3 minutes
> after grub loaded, I did some profile, and see guest is doing disk operations 
> by
> int13 BIOS procedure.
> 
> Even not consider the nested case, I saw there is a bug reporting normal VM
> boots slower than before (actually both qcow and disk image), see:
> http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1821
> Therefore I think the boot delay is just much lengthened in L2 guest.
> 
> I root caused this issue to a change in qemu, and I saw there is a lot of
> discussions on this topic. I didn't see the final decision but later the 
> patch was
> checked in. Could anybody helps to revisit this commit and explain the final
> decision?
> http://lists.xen.org/archives/html/xen-devel/2012-03/msg02072.html
> 
> Thanks,
> Dongxiao
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxx
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel