From owner-svn-src-head@freebsd.org Wed Mar 14 17:16:58 2018 Return-Path: Delivered-To: svn-src-head@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 CEA12F2C02E for ; Wed, 14 Mar 2018 17:16:58 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 635C96BE7D for ; Wed, 14 Mar 2018 17:16:58 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x235.google.com with SMTP id l12so5226610ioc.10 for ; Wed, 14 Mar 2018 10:16:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=qMy42KClhMDzjHxMoAr4dnI+vIVkfLrBRK6G0cbiiZs=; b=ldERe3k2XvDyI5jbg8IVce4kz/LOXIJO9PffmP3mERf2e5NOmsMfbXOY/PnWXU0Dia 2wjfiB7Wwczf6uLDgEuFkXWnHYdRPlkzQ5B/VcFgG1IMuqlIcI3Y7PD4QdM1Ie8PNqXe tZUhi+p+acFJZIcuuOJH2psa5DUFi0+UAd2oMAIpP0wlu345zs6bUHMHrOc+QDkbG6ZU k1SOvoiWnh49BCrPmlnRvcWyfStkeQKCb3NUWgyT3WvnRrKiE9s1Xb937OYZ3WoE3Eku Cfu86aKZ9+Y7b2108zznvDOgvglz2xcys8xsA1Y6vdRpOf2Ir+U89Q7eBywjrDmkKUJ3 Q+UQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=qMy42KClhMDzjHxMoAr4dnI+vIVkfLrBRK6G0cbiiZs=; b=Qlo0wRS2ml+mNtXhfD+jEEi4uqTH7UpxmaNHh+/g+DrIO/eWr1knZ1w3RdWBlPTKEy Etz/sjeXpWNHIW7P74j2gY329DgMEj/0/2D/a3gGUCmxjqh/JhKHPxQzvQ1VpX46EdzJ QJ5O/P0dWnpgGk8u2DddCZtqBgUamOOkNu/zOvYjeU2uekQ9p5NBbU4/Hbd3IUcFCzKX n78wFOpnWx2y4Icj4XCmpnG3Q+QwbXSznSgQ22rZhII/J5yeOyKiPmmdCbRefMd2IczY 5enhaQZE4HR9P5S58XzIjWt+yzeHukbWqXYD8t1wVNdOE96c2KlfgGHiKBcHkzcMac3d Hjjw== X-Gm-Message-State: AElRT7HLg3I0ax49T6EeOuVzs5wp/4FGOO14qhNaZ7rcPnOW7zH3EO+m /BP/BluloJRQhibuEFoOoc2EE7jhX5m5rTSJBXFaIw== X-Google-Smtp-Source: AG47ELt9KF4HfadbqSET7nCzhfLO/0FcWX6Dy2d0jgfMK8lJ9KuGbnd7wUY+FJej5h9w4eYLFJbvtjcfW5hl3jamzgE= X-Received: by 10.107.18.162 with SMTP id 34mr5522556ios.168.1521047817533; Wed, 14 Mar 2018 10:16:57 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.203.196 with HTTP; Wed, 14 Mar 2018 10:16:56 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: <22796282-7844-4E9A-AC32-10B09822FD25@mac.com> References: <201803141644.w2EGioti046140@repo.freebsd.org> <22796282-7844-4E9A-AC32-10B09822FD25@mac.com> From: Warner Losh Date: Wed, 14 Mar 2018 11:16:56 -0600 X-Google-Sender-Auth: Nt8IVSvNg4Q03LsHOdK3LDq6Cas Message-ID: Subject: Re: svn commit: r330932 - in head/sys: cam/nvme dev/nvme To: Ravi Pokala Cc: Warner Losh , src-committers , svn-src-all@freebsd.org, svn-src-head@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.25 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: Wed, 14 Mar 2018 17:16:59 -0000 On Wed, Mar 14, 2018 at 11:08 AM, Ravi Pokala wrote: > Hi Warner, > > The TRIM command takes a buffer of range structures, and this change > consolidates multiple range structures into the buffer for a single TRIM > command, correct? Whereas the old functionality was to populate the buffe= r > with a single range structure? > > So if we wanted to trim ranges [P..T], [A..E], [K..O], the old > functionality would be: > > TRIM:[P..T] ; TRIM:[A..E] ; TRIM:[K..O] > > The new functionality would be: > > TRIM:[P..T], [A..E], [K..O] > > Right? Correct. This helps a lot, at least for the drives I have access to. I'm working on adaptive features to allow us to know when it will help. > + /* XXX -- Could collapse adjacent ranges, > but we don't for now */ > > + /* XXX -- Could limit based on total > payload size */ > > And that future enhancement would make it: > > TRIM:[A..E], [K..T] > > Is that correct? > Yes. That's right. This code doesn't do that now. We also need to work on read biasing and a few other things as well, independent of what we send down to the driver. That's the scheduling bits. Some of the dynamic stuff will be only in the dynamic scheduler, but we need to not do trims first. I think that a strategy of collecting N BIO_DELETEs before we send down the DSM TRIM to the drive rather than sending them down asap would be useful (with some reasonable timeout so things don't get stuck for too long). Collecting TRIMs don't hang anything in the system, except reclaiming blocks on delete, as far as I can tell... I accidentally queued 10M trims and didn't drain them for 8 hours w/o anybody but the graphs for the machine that report queue length noticing... Warner > Thanks, > > Ravi (rpokala@) > > =EF=BB=BF-----Original Message----- > From: on behalf of Warner Losh > > Date: 2018-03-14, Wednesday at 09:44 > To: , , < > svn-src-head@freebsd.org> > Subject: svn commit: r330932 - in head/sys: cam/nvme dev/nvme > > > Author: imp > > Date: Wed Mar 14 16:44:50 2018 > > New Revision: 330932 > > URL: https://svnweb.freebsd.org/changeset/base/330932 > > > > Log: > > Implement trim collapsing in nda > > > > When multiple trims are in the queue, collapse them as much as > > possible. At present, this usually results in only a few trims being > > collapsed together, but more work on that will make it possible to do > > hundreds (up to some configurable max). > > > > Sponsored by: Netflix > > > >