Date: Fri, 27 Dec 2019 22:00:40 +0000 From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> To: Warner Losh <imp@bsdimp.com> Cc: 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: gsched: modernize or remove? Message-ID: <22559.1577484040@critter.freebsd.dk> In-Reply-To: <CANCZdfovCe1UQmC%2B94QK5P-imLEBygoyQLDqNSdDPeYryoL=bA@mail.gmail.com> References: <6d466360-988f-e80d-3212-b6c479a5ec03@FreeBSD.org> <CANCZdfovCe1UQmC%2B94QK5P-imLEBygoyQLDqNSdDPeYryoL=bA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
-------- In message <CANCZdfovCe1UQmC+94QK5P-imLEBygoyQLDqNSdDPeYryoL=3DbA@mail.gma= il.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. >> as direct dispatch, unmapped I/O, stripesize/stripeoffset, resize, etc. >> Even if some of them may require just a proper declaration, it tells m= e >> that barely anybody used it seriously for years. But my primary concer= n >> is the `gsched insert` implementation. Right now I got to it since it >> is the last consumer of nstart/nend counters in GEOM, which I would lik= e >> to remove for performance reasons. But I also see tons of potential >> problems with idea of moving providers between unaware geoms. >> >> 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. Poul-Henning [1] Imagine one process doing lots of work on the inner tracks and another on the outher track, if either processes is fast enough, it can starve out the other one, because its work is always closer. Traditionally disksorts have had "no changing direction until you get to the extreme request" hacks to ensure some fairness, but that can get to to worst-case-seek-time per I/O request land. [2] Not sure if anybody has looked at this yet, otherwise: Good project to get your hands wet with disk-I/O and benchmarking. NB: Beware of clustering. -- = Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe = Never attribute to malice what can adequately be explained by incompetence= .
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?22559.1577484040>