Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 6 Apr 2018 09:58:52 +0200
From:      Borja Marcos <borjam@sarenet.es>
To:        Warner Losh <imp@bsdimp.com>
Cc:        "Eugene M. Zheganin" <eugene@zhegan.in>, FreeBSD-STABLE Mailing List <freebsd-stable@freebsd.org>
Subject:   Re: TRIM, iSCSI and %busy waves
Message-ID:  <8935E1F4-10DE-4621-8153-26AF851CC26E@sarenet.es>
In-Reply-To: <CANCZdfrQBqcb5ASPFGjLN=nif4bQ9vTjMtBuDaOvvUKkM7u3XA@mail.gmail.com>
References:  <92b92a3d-3262-c006-ed5a-dc2f9f4a5cb9@zhegan.in> <CANCZdfrQBqcb5ASPFGjLN=nif4bQ9vTjMtBuDaOvvUKkM7u3XA@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help

> On 5 Apr 2018, at 17:00, Warner Losh <imp@bsdimp.com> 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.





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8935E1F4-10DE-4621-8153-26AF851CC26E>