On Wed, Jul 13, 2016 at 12:48 +0200, Peter N. M. Hansteen wrote: > On Wed, Jul 13, 2016 at 12:39:14PM +0200, Christian R????ner wrote: > > > Hello, you should use virtio drivers for the disk in KVM. > > > > I already use virtio ;-) But there is no need for the BSD kernel to do > > further > > scheduling. > > I'm not at all there is a knob to twiddle here, but if there is, will you > realistically see any difference in performance (assuming this is about > shaving cycles off)? >
Christian has a point, there's no need to involve the default block number oriented elevator (nscan) for devices that don't care about this. Unfortunately, as it stands the NOOP elevator (called FIFO in OpenBSD) will only be used by disks properly advertising SCSI Thin Provisioning support like this SSD for example: sd0 at scsibus1 targ 0 lun 0: <ATA, Samsung SSD 850, EXM0> SCSI3 0/direct fixed naa.50025388a08facb7 sd0: 244198MB, 512 bytes/sector, 500118192 sectors, thin The controller in question (vioblk) must fake those SCSI pages to let sd(4) driver query them and select FIFO scheduler. It's not doing it at the moment. It's possible to change the default disk elevator to FIFO by changing BUFQ_DEFAULT define in /sys/sys/buf.h to BUFQ_FIFO and recompile the kernel. There's no way to change it in the runtime. I would argue that instead of faking SCSI pages, it must be possible for the controller to hint sd(4) drivers that FIFO scheduling is preferred.
