Re: sys/dev/dksubr.c may reorder requests

[Toby Karyadi <toby.karyadi%gmail.com@localhost>]

On 2014-05-19 14:25, Manuel Bouyer wrote:
> Hello,
> sys/dev/dksubr.c:dk_start() has this code:
>         while ((bp = bufq_get(dksc->sc_bufq)) != NULL) {
>                 if (di->di_diskstart(dksc, bp) != 0) {
>                         bufq_put(dksc->sc_bufq, bp);
>                         break;
>                 }
>         }
>
> This potentially causes a buffer to be dequeued and requeued.
> Even with disksort strategy, it seems that the order is not preserved.
> I noticed this with xbd(4) (xen's virtual disk driver), where its start 
> routine
> would get out of order requests as the pagedaemon (or the filesystem) 
> generate
> properly ordered writes. The attached patch fixes this issue, and with
> on a Xen guest I can see a dd if=/dev/zero of=file bs=1m count=1000 
> bump from
> less to 30MB/s to more than 100MB/s. This is likely because the 
> underlying
> disk has a strategy to detect sequential writes, which fails with the
> reordering caused by dk_start().
>
> It looks like xbd(4) is the only user of sys/dev/dksubr.c, which may be 
> why
> is has not been noticed earlier.
>
> Any objection to the attached patch ?

Yay! This works GREAT! I applied the diff on 6.1.4 source and my netbsd 
PV domU write performance improved from ~50MB/s to 100+MB/s using dd as 
you did. In my case 'file' is on an ffsv1 with bsize of 32k on xbd that 
is backed in dom0 by an LVM volume on a raidframe raid1. I used to use a 
3 disk raid5 with lvm on top of it to back the domU, and the write 
performance was just so terrible as compared to the raw disk 
performance, (like ~20MB/s vs ~100MB/s) such that I just changed my 
installation to use raid1 in dom0. Maybe this patch will fix it, I'll 
let you know.

Btw, in your patch, in the comments, did you mean 'resources', as 
opposed to 'ressources'?

Thanks a bunch,
Toby