Date: Sat, 28 Dec 2019 08:40:35 -0000 From: Luigi Rizzo <rizzo@iet.unipi.it> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: Warner Losh <imp@bsdimp.com>, Alexander Motin <mav@freebsd.org>, Luigi Rizzo <luigi@freebsd.org>, Pawel Jakub Dawidek <pjd@freebsd.org>, "freebsd-geom@FreeBSD.org" <freebsd-geom@freebsd.org>, "Conrad E. Meyer" <cem@freebsd.org>, "Andrey V. Elsukov" <ae@freebsd.org>, "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org>, Warner Losh <imp@freebsd.org> Subject: Re: [Probabile SPF]Re: gsched: modernize or remove? Message-ID: <CA%2BhQ2%2Bh_QErGEr-q5UAFS_W43nYGSG%2BgB2LG%2BHN6tQwnEicUPw@mail.gmail.com> In-Reply-To: <22559.1577484040@critter.freebsd.dk> References: <6d466360-988f-e80d-3212-b6c479a5ec03@FreeBSD.org> <CANCZdfovCe1UQmC%2B94QK5P-imLEBygoyQLDqNSdDPeYryoL=bA@mail.gmail.com> <22559.1577484040@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Dec 27, 2019 at 2:00 PM Poul-Henning Kamp <phk@phk.freebsd.dk> wrote: > -------- > In message <CANCZdfovCe1UQmC+94QK5P-imLEBygoyQLDqNSdDPeYryoL= > bA@mail.gmail.com> > , Warner Losh writes: > >On Fri, Dec 27, 2019 at 10:53 AM Alexander Motin <mav@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CA%2BhQ2%2Bh_QErGEr-q5UAFS_W43nYGSG%2BgB2LG%2BHN6tQwnEicUPw>