OK, I''ve got my first-cut block device implementation over xenshare: http://ozlabs.org/~rusty/xen/bundles/xen-share-2006-02-17.hg The block server (ie. backend) is a userspace process in dom0 which has the bonus feature of crashing dom0 on exit! That would suggest that this is not production code, but might make nice bedtime reading. Here''s the compulsory benchmark numbers (same machine, uniproc 3GHz Pentium 4), ext2 filesystem in a file in dom0 served to dom1: Current block device: dd if=/dev/zero of=test bs=1M count=1000: 71.5527 seconds dbench 10: 48.685 MB/sec Share block device: dd if=/dev/zero of=test bs=1M count=1000: 31.0611 seconds dbench 10: 106.997 MB/sec Cheers! Rusty. -- ccontrol: http://ozlabs.org/~rusty/ccontrol _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> Here''s the compulsory benchmark numbers (same machine, uniproc 3GHz > Pentium 4), ext2 filesystem in a file in dom0 served to dom1: > > Current block device: > dd if=/dev/zero of=test bs=1M count=1000: 71.5527 secondsBy my accounting that looks to be about 14 MB/s off your block device using the existing split drivers... If you can''t saturate the disk on a 3 Ghz box I''d have to think that something has gone desperately wrong. Has a block performance bug slid in to unstable or something? ;) I don''t doubt that better memory performance can be achieved by adjusting event notification frequency/batching -- as you pointed out earlier... but block devices are a pretty weird place to try to win. I''d expect the numbers from the two tests you''re running to be identical -- and bottlenecked on the disk. By a lot. a. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Thu, 2006-02-16 at 21:14 -0800, Andrew Warfield wrote:> > Here''s the compulsory benchmark numbers (same machine, uniproc 3GHz > > Pentium 4), ext2 filesystem in a file in dom0 served to dom1: > > > > Current block device: > > dd if=/dev/zero of=test bs=1M count=1000: 71.5527 seconds > > > By my accounting that looks to be about 14 MB/s off your block device > using the existing split drivers... If you can''t saturate the disk on > a 3 Ghz box I''d have to think that something has gone desperately > wrong.Yes, I think so too. Frankly, I expected my implementation''s performance to be bad, because the hypervisor copies to dom0 userspace, which then writes to the disk. This is great for implementing COW and other specials, but not optimal if you''re just shunting blocks to/from disk. Now, in dom0 this operation takes about 27 seconds (38 MB/sec). My code gets about 33.7 MB/sec. Now, page-table ops involved in granting buffers will hurt you some, but I''d expect nice big batches of ops from this example to amortize that nicely. I cannot explain this level of pain, but over 10 runs it was consistent.> I don''t doubt that better memory performance can be achieved by > adjusting event notification frequency/batching -- as you pointed out > earlier... but block devices are a pretty weird place to try to win. > I''d expect the numbers from the two tests you''re running to be > identical -- and bottlenecked on the disk. By a lot.Hmm, my dom0 only has 128MB of RAM, and my dom1 64MB. Wonder if I''m getting bad behaviour due to small amounts of memory? I was just happy to get my code working, but I''ll dig deeper next week. Cheers, Rusty. -- ccontrol: http://ozlabs.org/~rusty/ccontrol _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 17 Feb 2006, at 07:22, Rusty Russell wrote:>> I don''t doubt that better memory performance can be achieved by >> adjusting event notification frequency/batching -- as you pointed out >> earlier... but block devices are a pretty weird place to try to win. >> I''d expect the numbers from the two tests you''re running to be >> identical -- and bottlenecked on the disk. By a lot. > > Hmm, my dom0 only has 128MB of RAM, and my dom1 64MB. Wonder if I''m > getting bad behaviour due to small amounts of memory? > > I was just happy to get my code working, but I''ll dig deeper next week.Perhaps one backend is hitting the buffer cache and the other is bypassing it? -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel