From owner-freebsd-geom@freebsd.org Fri Dec 27 22:00:44 2019 Return-Path: <owner-freebsd-geom@freebsd.org> Delivered-To: freebsd-geom@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 0CE0E1D0B12; Fri, 27 Dec 2019 22:00:44 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 47l13b309gz4cF2; Fri, 27 Dec 2019 22:00:43 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (v-critter.freebsd.dk [192.168.55.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by phk.freebsd.dk (Postfix) with ESMTPS id 825FA1AF135; Fri, 27 Dec 2019 22:00:41 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.15.2/8.15.2) with ESMTPS id xBRM0fst022561 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 27 Dec 2019 22:00:41 GMT (envelope-from phk@critter.freebsd.dk) Received: (from phk@localhost) by critter.freebsd.dk (8.15.2/8.15.2/Submit) id xBRM0e5Q022560; Fri, 27 Dec 2019 22:00:40 GMT (envelope-from phk) 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? In-reply-to: <CANCZdfovCe1UQmC+94QK5P-imLEBygoyQLDqNSdDPeYryoL=bA@mail.gmail.com> From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> References: <6d466360-988f-e80d-3212-b6c479a5ec03@FreeBSD.org> <CANCZdfovCe1UQmC+94QK5P-imLEBygoyQLDqNSdDPeYryoL=bA@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <22558.1577484040.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Fri, 27 Dec 2019 22:00:40 +0000 Message-ID: <22559.1577484040@critter.freebsd.dk> X-Rspamd-Queue-Id: 47l13b309gz4cF2 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of phk@critter.freebsd.dk designates 130.225.244.222 as permitted sender) smtp.mailfrom=phk@critter.freebsd.dk X-Spamd-Result: default: False [-0.32 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-0.52)[-0.520,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.dk]; NEURAL_HAM_MEDIUM(-0.85)[-0.853,0]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_SEVEN(0.00)[9]; IP_SCORE(0.05)[ip: (0.07), ipnet: 130.225.0.0/16(0.08), asn: 1835(0.10), country: EU(-0.00)]; FORGED_SENDER(0.30)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:1835, ipnet:130.225.0.0/16, country:EU]; SUBJECT_ENDS_QUESTION(1.00)[]; FROM_NEQ_ENVFROM(0.00)[phk@phk.freebsd.dk,phk@critter.freebsd.dk] X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GEOM-specific discussions and implementations <freebsd-geom.freebsd.org> List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-geom>, <mailto:freebsd-geom-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/freebsd-geom/> List-Post: <mailto:freebsd-geom@freebsd.org> List-Help: <mailto:freebsd-geom-request@freebsd.org?subject=help> List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-geom>, <mailto:freebsd-geom-request@freebsd.org?subject=subscribe> X-List-Received-Date: Fri, 27 Dec 2019 22:00:44 -0000 -------- 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= .