Date: Wed, 14 Mar 2018 11:16:56 -0600 From: Warner Losh <imp@bsdimp.com> To: Ravi Pokala <rpokala@mac.com> Cc: Warner Losh <imp@freebsd.org>, src-committers <src-committers@freebsd.org>, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r330932 - in head/sys: cam/nvme dev/nvme Message-ID: <CANCZdfqyxSf-ccPpEgvNe7e47EgpFhWNUjbvqpt89FXB5Ftbtg@mail.gmail.com> In-Reply-To: <22796282-7844-4E9A-AC32-10B09822FD25@mac.com> References: <201803141644.w2EGioti046140@repo.freebsd.org> <22796282-7844-4E9A-AC32-10B09822FD25@mac.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Mar 14, 2018 at 11:08 AM, Ravi Pokala <rpokala@mac.com> 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: <owner-src-committers@freebsd.org> on behalf of Warner Losh > <imp@FreeBSD.org> > Date: 2018-03-14, Wednesday at 09:44 > To: <src-committers@freebsd.org>, <svn-src-all@freebsd.org>, < > 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 > > > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfqyxSf-ccPpEgvNe7e47EgpFhWNUjbvqpt89FXB5Ftbtg>