Date: Wed, 05 Sep 2018 15:07:16 -0700 From: Kirk McKusick <mckusick@mckusick.com> To: Mark Millard <marklmi@yahoo.com> Cc: bob prohaska <fbsd@www.zefox.net>, FreeBSD Filesystems <freebsd-fs@FreeBSD.org> Subject: Re: CFT: TRIM Consolodation on UFS/FFS filesystems Message-ID: <201809052207.w85M7GS2000773@chez.mckusick.com> In-Reply-To: <A751682B-6718-4E9F-87DB-2C7AA7076854@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> From: Mark Millard <marklmi@yahoo.com> > Subject: Re: CFT: TRIM Consolodation on UFS/FFS filesystems > Date: Wed, 5 Sep 2018 00:06:54 -0700 > Cc: bob prohaska <fbsd@www.zefox.net>, > FreeBSD Filesystems <freebsd-fs@FreeBSD.org> > To: Kirk McKusick <mckusick@mckusick.com> > > On 2018-Sep-4, at 10:20 PM, Kirk McKusick <mckusick at mckusick.com> wrote: > >> Thanks for the report. Do you have a sense/measurement that the >> build times better/same/worse than without the consolidation? > > ... > > But installworld is far more I/O bound and does take something > like 11 or 12 minutes in this context. (installkernel is also > more I/O bound but takes far less time.) > > I have a record of an updating installworld for > clang-cortexA53-installworld-poud already with consolidation > turned on . . . > > Start time: 2018-09-04:12:48:14 > End time: 2018-09-04:12:59:54 (so 11 min 40 sec or so elapsed) > typescript log size: 8698790 > > So after the poudriere/pkg activity I could repeat the > "-j4 installworld distrib-dirs distribution DB_FROM_SRC=1 > DESTDIR=/usr/obj/DESTDIRs/clang-cortexA53-installworld-poud" > with the new consolidation turned off. (That would leave > active the mmc/sd code's consolidation that Ian L. > referenced.) > > I could also try yet again but with trim disabled for the file > system, giving a 3rd contrasting case. > > Would these comparisons help? > > === > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) The above three comparisons on the (relatively) I/O bound installworld would be useful. Even if the TRIM consolidation does not help, it is useful to know that it does not hurt. And running without TRIM would also be a useful data point to measure the cost/savings of doing TRIM. It is a bit tricky to just turn off TRIM and then measure it, because in the immediate aftermath of its having been used, it will leave behind a legacy of easier to use flash areas yet not have the cost of keeping them cleaned up. So, it might initially look like enabling TRIM is a bad idea. Thus you would have to run many installworlds without TRIM enabled to see what the long-term result of not using TRIM turns out to be. Kirk McKusick
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201809052207.w85M7GS2000773>