From owner-svn-src-head@freebsd.org Tue Dec 17 00:54:32 2019 Return-Path: Delivered-To: svn-src-head@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 934BE1D384C for ; Tue, 17 Dec 2019 00:54:32 +0000 (UTC) (envelope-from kevin.bowling@kev009.com) Received: from mail-il1-x12b.google.com (mail-il1-x12b.google.com [IPv6:2607:f8b0:4864:20::12b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47cKRC5kMhz4YbJ for ; Tue, 17 Dec 2019 00:54:31 +0000 (UTC) (envelope-from kevin.bowling@kev009.com) Received: by mail-il1-x12b.google.com with SMTP id t8so5554801iln.4 for ; Mon, 16 Dec 2019 16:54:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kev009.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DaO6v1j+hMOKFc2lVyjN8eIBdsz79JhsMdpXPG6syJw=; b=kr8cyuyKcH9etVaP3p67q+gGMbcv/ix3qj8wV5mwP+CuPG8eIqubXKlQNLgHa3H6Qx pXByVW1xFbwSIMAJ5hXF/cqlyNbkIYGbJkXsMsN0ugD/Qp6clV8GhoaSjVPgEMsZD0lv RrFDlkxN8UX3h52x3qxmP1FIGPFpzt+QS6+zg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=DaO6v1j+hMOKFc2lVyjN8eIBdsz79JhsMdpXPG6syJw=; b=tksBlyZngqAUwLgVM3s1FMi4VXZdLWCGwX2FLksjNLHpQw2c4lzJs+k4arDCaqQWmL rqmINxzl702bEIgCOaSMAeoTcIP+SKMLarMhWV5PWOtquoGCuB3aJw6C/jNsaA0Xr1ZE sA98FjoizFKxXQE8M/zBPly4ovR4mu3wNOwQlChz6rLt902ur5SayYK3xHr2vQWUfScA IF1oJTBwNcWabgJGB8Fa+tuDpdH2Fnr26V6PI1zyiqI0kD6sGcZnxDKz9A0yKzoiJgUa x6npdVUBuImA8KKcKmoWqj1ybMYnm/T6UWU5V2q7j+4WrHSL8ZyNn+USaaRFc0lZL3Xo t92A== X-Gm-Message-State: APjAAAXupsTd/mg6f9oyjQbl4OqiSSH0ro9d5ISsaa3NUAfTv8FqWSFp wT/3IiHQHm9iGQIVQQdjVPbzIkdZMbqGfKZVMgC09A== X-Google-Smtp-Source: APXvYqxI5m0wQhQojmNxqzFb68ju2co086dL8F8ajiiPpGHOCtQJW9XqN1Q5l+fR40qH3gT+JFXLrbbsNDffqO63qqA= X-Received: by 2002:a92:8441:: with SMTP id l62mr1777782ild.85.1576544070396; Mon, 16 Dec 2019 16:54:30 -0800 (PST) MIME-Version: 1.0 References: <201912170013.xBH0DjZY090730@repo.freebsd.org> <5b944742-51ff-861b-10bc-c01d67c02933@multiplay.co.uk> In-Reply-To: <5b944742-51ff-861b-10bc-c01d67c02933@multiplay.co.uk> From: Kevin Bowling Date: Mon, 16 Dec 2019 17:54:19 -0700 Message-ID: Subject: Re: svn commit: r355837 - head/sys/cam To: Steven Hartland Cc: Warner Losh , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org X-Rspamd-Queue-Id: 47cKRC5kMhz4YbJ X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none (invalid DKIM record) header.d=kev009.com header.s=google header.b=kr8cyuyK; dmarc=none; spf=pass (mx1.freebsd.org: domain of kevin.bowling@kev009.com designates 2607:f8b0:4864:20::12b as permitted sender) smtp.mailfrom=kevin.bowling@kev009.com X-Spamd-Result: default: False [-3.70 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[svn-src-head@freebsd.org]; DMARC_NA(0.00)[kev009.com]; URI_COUNT_ODD(1.00)[9]; RCPT_COUNT_FIVE(0.00)[5]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[kev009.com:~]; RCVD_IN_DNSWL_NONE(0.00)[b.2.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; R_DKIM_PERMFAIL(0.00)[kev009.com:s=google]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; IP_SCORE(-2.40)[ip: (-7.84), ipnet: 2607:f8b0::/32(-2.19), asn: 15169(-1.90), country: US(-0.05)]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2019 00:54:32 -0000 On Mon, Dec 16, 2019 at 5:44 PM Steven Hartland < steven.hartland@multiplay.co.uk> wrote: > Sticky keyboard there Warner? LOL > On a more serious note the fact that the controllers lie about the > underlying > location of data, the impact of skipping the TRIM requests can have a > much more > serious impact than one might think depending on the drive, so this type = of > optimisation can significantly harm performance instead of increasing it. > > This was the main reasons we sponsored the initial ZFS TRIM > implementation; as > drive performance go so bad with no TRIM that SSD's performed worse than > HDD's. Have you been able to test the new OpenZFS/ZoF TRIM? I notice the current FBSD one gets quite beleaguered with highly concurrent poudriere as the snapshots are being reaped, I.e TRIMs totally swamp r/w ops on the Plextor PCIe SSD I have. I haven=E2=80=99t tried ZoF on this ma= chine yet since it is my main workstation but will do so once it is ready for mainline. > Now obviously this was some time ago, but I wouldn't be surprised if > there's bad > hardware / firmware like this still being produced. > > Given that might be a good idea to make this optional, possibly even opt > in not opt > out? > > Regards > Steve > > On 17/12/2019 00:13, Warner Losh wrote: > > Author: imp > > Date: Tue Dec 17 00:13:45 2019 > > New Revision: 355837 > > URL: https://svnweb.freebsd.org/changeset/base/355837 > > > > Log: > > Implement bio_speedup > > > > React to the BIO_SPEED command in the cam io scheduler by completing > > as successful BIO_DELETE commands that are pending, up to the length > > passed down in the BIO_SPEEDUP cmomand. The length passed down is a > > hint for how much space on the drive needs to be recovered. By > > completing the BIO_DELETE comomands, this allows the upper layers to > > allocate and write to the blocks that were about to be trimmed. Sinc= e > > FreeBSD implements TRIMSs as advisory, we can eliminliminate them an= d > > go directly to writing. > > > > The biggest benefit from TRIMS coomes ffrom the drive being able t > > ooptimize its free block pool inthe log run. There's little nto no > > bene3efit in the shoort term. , sepeciall whn the trim is followed b= y > > a write. Speedup lets us make this tradeoff. > > > > Reviewed by: kirk, kib > > Sponsored by: Netflix > > Differential Revision: https://reviews.freebsd.org/D18351 > > > > Modified: > > head/sys/cam/cam_iosched.c > > > > Modified: head/sys/cam/cam_iosched.c > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > --- head/sys/cam/cam_iosched.c Tue Dec 17 00:13:40 2019 > (r355836) > > +++ head/sys/cam/cam_iosched.c Tue Dec 17 00:13:45 2019 > (r355837) > > @@ -1534,6 +1534,41 @@ cam_iosched_queue_work(struct cam_iosched_softc > *isc, > > { > > > > /* > > + * A BIO_SPEEDUP from the uppper layers means that they have a > block > > + * shortage. At the present, this is only sent when we're trying = to > > + * allocate blocks, but have a shortage before giving up. > bio_length is > > + * the size of their shortage. We will complete just enough > BIO_DELETEs > > + * in the queue to satisfy the need. If bio_length is 0, we'll > complete > > + * them all. This allows the scheduler to delay BIO_DELETEs to > improve > > + * read/write performance without worrying about the upper layers= . > When > > + * it's possibly a problem, we respond by pretending the > BIO_DELETEs > > + * just worked. We can't do anything about the BIO_DELETEs in the > > + * hardware, though. We have to wait for them to complete. > > + */ > > + if (bp->bio_cmd =3D=3D BIO_SPEEDUP) { > > + off_t len; > > + struct bio *nbp; > > + > > + len =3D 0; > > + while (bioq_first(&isc->trim_queue) && > > + (bp->bio_length =3D=3D 0 || len < bp->bio_length)) { > > + nbp =3D bioq_takefirst(&isc->trim_queue); > > + len +=3D nbp->bio_length; > > + nbp->bio_error =3D 0; > > + biodone(nbp); > > + } > > + if (bp->bio_length > 0) { > > + if (bp->bio_length > len) > > + bp->bio_resid =3D bp->bio_length - len; > > + else > > + bp->bio_resid =3D 0; > > + } > > + bp->bio_error =3D 0; > > + biodone(bp); > > + return; > > + } > > + > > + /* > > * If we get a BIO_FLUSH, and we're doing delayed BIO_DELETEs the= n > we > > * set the last tick time to one less than the current ticks minu= s > the > > * delay to force the BIO_DELETEs to be presented to the client > driver. > > @@ -1919,8 +1954,8 @@ DB_SHOW_COMMAND(iosched, cam_iosched_db_show) > > db_printf("Trim Q len %d\n", biolen(&isc->trim_queue)); > > db_printf("read_bias: %d\n", isc->read_bias); > > db_printf("current_read_bias: %d\n", isc->current_read_bias); > > - db_printf("Trims active %d\n", isc->pend_trim); > > - db_printf("Max trims active %d\n", isc->max_trim); > > + db_printf("Trims active %d\n", isc->pend_trims); > > + db_printf("Max trims active %d\n", isc->max_trims); > > } > > #endif > > #endif > > _______________________________________________ > svn-src-head@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/svn-src-head > To unsubscribe, send any mail to "svn-src-head-unsubscribe@freebsd.org" >