Dump flush write performance

Two changes to avoid disk driver using up kernel memory and triggering oom-killer while creating guest dump to a disk file:

1) Decreased write chunks from 16MB to 2MB;
2) Flush (fsync) after each 2MB write.

To make sure we don't suffer significant write performance penalty, each of the following cases have been tested several times to dump a 1GB guest to a file on a SAN disk:

With current code (16MB writes, sync once after all writes); ~38s 16MB writes, sync after each write: ~46s
2MB writes, sync after each write: ~49s

Sync-often costs us about 20%, smaller-write-size costs another 8%. The total is less than 30% and about 10 seconds more for a 1GB guest.

diff -r 9d263e1fcd02 tools/libxc/xc_core.c
@@ -56,7 +56,7 @@
 #include <unistd.h>
 
 /* number of pages to write at a time */
-#define DUMP_INCREMENT (4 * 1024)
+#define DUMP_INCREMENT (512)
 
 /* Don't yet support cross-address-size core dump */
 #define guest_width (sizeof (unsigned long))

@@ -875,7 +875,7 @@ static int local_file_dump(void *args, c
     if (length >= DUMP_INCREMENT*PAGE_SIZE) {
         // Now dumping pages -- make sure we discard clean pages from
         // the cache after each write
-        discard_file_cache(da->fd, 0 /* no flush */);
+        discard_file_cache(da->fd, 1 /* flush */);
     }
 
     return 0;

_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel

I don't think we've had any reports of core dumping causing oom killer to kick in. It seems a bit unlikely after all, unless you're really running dom0 close to the wire. A user process write()ing a big file shouldn't be able to trigger oom killer imo.

-- Keir