-
Notifications
You must be signed in to change notification settings - Fork 48
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Not Good I/O Performance of /dev/nbdx #31
Comments
Careful measuring disk I/O in user space and kernel space. Kernel does not have disk caching or readahead whereas userspace is more likely has it. When testing I/O performance, make sure to use DIRECT access. That way you are assessing the block device performance. |
@bandi13 Thanks for your comment. I have already used direct accessing to measure I/O performance of those block devices, no matter they were in user space or kernel space. I think the low performance of |
What I would do is simplify your setup and just use a block of memory (like tmpfs), and do your fio test on it, then attach the nbd layer and redo the test to see the performance difference. You may be right that the malloc and free of all the buffers may not be efficient (though it shouldn't cause a 5x performance loss), but how would you do it otherwise? Have your own local memory pool? |
@bandi13 Thanks for your comment.
The fio configure file template is as follows:
I think the performance loss of BUSE/nbd for high performance device is worth to notice. However now, I don't have a good idea about how to export the high performance device into kernel space (to become a /dev/xxx). BUSE may be not a good choice for me, and I have to create my own kernel model to do this work. |
Could you try your experiment with 'ioengine=sync'? With your test, you're issuing 128 concurrent reads which the kernel can reorder based on how they are laid out on disk to make it more efficient to read, whereas with NBD it comes in as the asynchronous calls are handled. Also, it looks like SPDK can use NDB directly to expose the disk (see here). What are you trying to test with BUSE? SPDK is essentially doing the same thing as BUSE. |
Hi @bandi13 ,thanks very much for your comment. I nearly forget that SPDK supporting NBD directly, and the SPDK NBD could provide about 600MB/s random reading bandwidth (based on a SPDK zero device, tested by fio + libaio), which is better than the result of my BUSE implementation. The Besides, NBD couldn't provide scalability, which means I can't get better performance via increasing the number of working threads, no matter using SPDK NBD for BUSE. That's no good for my demand. So thanks again for your comments, and I think there is no way to export high performance device from SPDK into kernel, except writing my own special kernel driver. |
I mean the bandwidth of dm-zero (or spdk-zero) is scaling linearly with the addition of threads, but the bandwidth of NBD doesn't have this advantage. |
Create jobs! Guys. I have used BUSE to export a userspace block device (a SPDK defined block device) into kernel space, and it's easy to make it. But the I/O performance of the new block device (/dev/nbd0) is not so good.
fio -> /dev/nbd0 <--BUSE --> a SPDK block device
...... (kernel space).................(user space)
...... (reading 200MB/s) ........ (reading 1GB/s)
Like the schematic diagram showing above, I could get about 1GB/s bandwidth when I am reading the userspace block device, but there were only about 200MB/s on /dev/nbd0. Could you give me some advice to keep bandwidth along with exporting a user space block device into the kernel space (becoming a /dev/xxx). Thanks a lot!
The text was updated successfully, but these errors were encountered: