Date: Sun, 22 Jul 2012 11:08:37 -0500 (CDT) From: Bryan Venteicher <bryanv@daemoninthecloset.org> To: Dieter BSD <dieterbsd@engineer.com> Cc: hackers@freebsd.org, current@freebsd.org Subject: Re: Awful FreeBSD 9 block IO performance in KVM Message-ID: <738102528.760.1342973317543.JavaMail.root@sage.daemoninthecloset.org> In-Reply-To: <20120722061933.298410@gmx.com>
next in thread | previous in thread | raw e-mail | index | archive | help
----- Original Message ----- > From: "Dieter BSD" <dieterbsd@engineer.com> > To: hackers@freebsd.org, current@freebsd.org > Sent: Sunday, July 22, 2012 1:19:32 AM > Subject: Re: Awful FreeBSD 9 block IO performance in KVM > > >>> da0: 3.300MB/s transfers > >>> da0: Command Queueing enabled > > > > root@freebsd:/root # dd if=/dev/zero of=/dev/da1 bs=16384 > > count=262144 > > > > 4294967296 bytes transferred in 615.840721 secs (6974153 bytes/sec) > > 1) Does a larger block size (bs=1m) help? > > 2) That's roughly the speed I'd expect without queueing. Is it really > making effective use of queueing, or is something limiting queueing to > one transfer at a time? The likely fix here is basically do vtblk_startio() in a separate kproc that vtblk_strategy() enqueues bio's to. This has been on my todo for a while, but haven't had the time. Also, the use of bioq_disksort() probably doesn't gain much for virtualized disks, but I never found much of a difference in my testing. > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to > "freebsd-hackers-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?738102528.760.1342973317543.JavaMail.root>