> Am 13.07.2016 um 13:07 schrieb Mike Belopuhov <[email protected]>: > > 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.
Thank you very much for your answer. I think, I will leave it as is at the moment. Christian
