From owner-svn-src-all@freebsd.org Wed Mar 14 17:16:59 2018 Return-Path: Delivered-To: svn-src-all@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 0EB01F2C02F for ; Wed, 14 Mar 2018 17:16:59 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (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 946316BE7F for ; Wed, 14 Mar 2018 17:16:58 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x22e.google.com with SMTP id k21so5259442ioc.2 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=bd5yo+wRYT/3esHF/8pxiZHzkbgxsQuxronFzkF86I4/S0D08DCZr3CIq1uG6PkL8J 5/42enAb1FcJUbaLm76ZrXstpvieRaFRTIm3NZ5cBebWqmuGpgDPpm6jAI9+m14+lZLi 0Q04AEW0lMoPDp2nD4t3IIhtsgBej/ojPueBjrpihYmNY+bee/5802yvDx5PvdjTcmHb U7XmHMugwv/f+vRsnZPEUy0zd3dVrivp2Dz+fjVQSBUXJspTN0W0lgn3y9FJPzMifRZN B2IEUv/Ies8+swZOYxBa78/jATuYeBa0ipt0IfVpRHn6nTBwcLkfqvhInmZ/rR7KsgTY A8Wg== X-Gm-Message-State: AElRT7G/Rw3aj5sHFJbfuUFGeTwr4gZjB2Q+tSxs+6TAxS6jT+1x/rpl blPSSeqt2G/KQHC7NqbkjqHSxkBG243gU00PXN2i7Q== 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-all@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" 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 > > > >