On Fri, Dec 27, 2019 at 2:00 PM Poul-Henning Kamp <p...@phk.freebsd.dk>
wrote:

> --------
> In message <CANCZdfovCe1UQmC+94QK5P-imLEBygoyQLDqNSdDPeYryoL=
> b...@mail.gmail.com>
> , Warner Losh writes:
> >On Fri, Dec 27, 2019 at 10:53 AM Alexander Motin <m...@freebsd.org> wrote:
> >
> >> Hi,
> >>
> >> As I can see, gsched code was not really maintained for the last 10
> >> years since being added.
> ...
> >> So my question is: does it make sense to try fix/modernize it, or it
> >> just be easier to remove it?  Does anybody still use it, or see some
> >> future for it?
>
> Gsched was always a weird thing IMO.
>
> I was happy to see that you could do stuff like that with GEOM, but
> for the life of me I could never figure out why you would want to
> do it with GEOM which is a very low-information environment when
> it comes to scheduling decisions.
>
> I belive the original inspiration was "Anticipatory disk-scheduling"
> which tries to mitigate some starvation issues which you can have
> with a normal elevator disksort on systems with very few ioreq
> sources[1].
>
> With SSDs all but having erased seek-time from the surface of the
> planet, and huge caches in drives, controllers and pretty much
> everywhere else people have been able to squeeze one in, it is not
> even obvious to me if it makes sense to have any disksort in the
> first place[2], much less gssched.
>

phk's summary is perfectly accurate. the practical motivation
at the time was to make sure that svn operations and streaming
I/O would not kill each other, but since we all switched to SSDs
there is no use case anymore and so I am ok with removing gsched.

As to why it was in geom rather than elsewhere: that was a very
convenient place to do scheduling in a generic way, rather than
replicate it in scsi/hdd/other lower level drivers.

cheers
luigi
_______________________________________________
freebsd-geom@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-geom
To unsubscribe, send any mail to "freebsd-geom-unsubscr...@freebsd.org"

Reply via email to