From owner-freebsd-stable@freebsd.org Fri Apr 6 08:07:09 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 46BE2F8FDD5 for ; Fri, 6 Apr 2018 08:07:09 +0000 (UTC) (envelope-from borjam@sarenet.es) Received: from cu01176b.smtpx.saremail.com (cu01176b.smtpx.saremail.com [195.16.151.151]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D81A86BBAE for ; Fri, 6 Apr 2018 08:07:08 +0000 (UTC) (envelope-from borjam@sarenet.es) Received: from [172.16.8.141] (unknown [192.148.167.11]) by proxypop01.sare.net (Postfix) with ESMTPA id 1C0499DDE51; Fri, 6 Apr 2018 09:58:52 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Subject: Re: TRIM, iSCSI and %busy waves From: Borja Marcos In-Reply-To: Date: Fri, 6 Apr 2018 09:58:52 +0200 Cc: "Eugene M. Zheganin" , FreeBSD-STABLE Mailing List Content-Transfer-Encoding: quoted-printable Message-Id: <8935E1F4-10DE-4621-8153-26AF851CC26E@sarenet.es> References: <92b92a3d-3262-c006-ed5a-dc2f9f4a5cb9@zhegan.in> To: Warner Losh X-Mailer: Apple Mail (2.3445.6.18) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2018 08:07:09 -0000 > On 5 Apr 2018, at 17:00, Warner Losh wrote: >=20 > I'm working on trim shaping in -current right now. It's focused on = NVMe, > but since I'm doing the bulk of it in cam_iosched.c, it will = eventually be > available for ada and da. The notion is to measure how long the TRIMs = take, > and only send them at 80% of that rate when there's other traffic in = the > queue (so if trims are taking 100ms, send them no faster than 8/s). = While > this will allow for better read/write traffic, it does slow the TRIMs = down > which slows down whatever they may be blocking in the upper layers. = Can't > speak to ZFS much, but for UFS that's freeing of blocks so things like = new > block allocation may be delayed if we're almost out of disk (which we = have > no signal for, so there's no way for the lower layers to prioritize = trims > or not). Have you considered "hard" shaping including discarding TRIMs when = needed? Remember that a TRIM is not a write, which is subject to a contract with = the application, but a better-if-you-do-it operation.=20 Otherwise, as you say, you might be blocking other operations in the = upper layers. I am assuming here that with many devices doing TRIMs is better than not = doing them. And in case of queue congestion doing *some* TRIMs should be better than = doing no TRIMs at all. Yep, not the first time I propose something of the sort, but my queue of = suggestions=20 to eventually discard TRIMs doesn=E2=80=99s implement the same method ;) Borja.