Op 02/05/16 om 02:49 schreef Warren Block:
> CAM I/O Scheduler
> I/O Scheduling in FreeBSD's CAM Subsystem (PDF) URL:
> The BSDCan 2015 Talk URL: https://www.youtube.com/watch?v=3WqOLolj5EU
> Contact: Warner Losh <wl...@netflix.com>
> An enhanced CAM I/O scheduler has been committed to the tree. By
> default, this scheduler implements the old behavior. In addition, an
> advanced adaptive scheduler is available. Along with the scheduler,
> SATA disks can now use Queued Trims with devices that support them.
> Details about the new scheduler are available in the I/O Scheduling in
> FreeBSD's CAM Subsystem article (PDF) or from the BSDCan 2015 talk.
> The adaptive I/O scheduler is disabled by default, but can be enabled
> with options CAM_ADAPTIVE_IOSCHED in the kernel config file. This
> scheduler allows favoring reads over writes (or vice versa),
> controlling the IOPs, bandwidth, or concurrent operations (read,
> trim), and permits the selection of static or dynamic control of these
> operations. In addition, a number of statistics are collected for
> operations that are published via sysctl. One advanced use for the
> adaptive I/O scheduler is to compensate for deficiencies in some
> consumer-grade SSDs. These SSDs exhibit a performance cliff if too
> data is written to them too quickly due to internal garbage
> Without the I/O scheduler, read and write performance drop
> substantially once garbage collection kicks in. The adaptive I/O
> scheduler can be configured to monitor read latency. As read latency
> climbs, the I/O scheduler reduces the allowed write throughput, within
> limits, to attempt to maximize read performance. A simple use of the
> adaptive I/O scheduler would be to limit write bandwidth, IOPs or
> concurrent operations statically.
> Future work on the I/O scheduler will be coupled with improvements to
> the upper layers. The upper layers will be enhanced to communicate how
> urgent I/O requests are. The I/O scheduler will inform the upper
> of how full the I/O queues are, so less urgent I/O can be submitted to
> the lower layers as quickly as possible without overwhelming the lower
> layers or starving other devices of requests.
> This project was sponsored by Netflix.
I updated my source today, but CAM_ADAPTIVE_IOSCHED yields an error
about an unknown option.
If I use CAM_NETFLIX_IOSCHED the kernel compiles.
Is the name CAM_NETFLIX_IOSCHED changing to CAM_ADAPTIVE_IOSCHED?
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"