CFT: TRIM Consolodation on UFS/FFS filesystems

[Mark Millard]

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?


buildworld buildkernel is far from I/O bound overall (elapsed time)
when built via clang when the llvm materials are being built in this
context: CPU/RAM bound. (I watched gstat -pd and top -CawSores for
evidence of this.) Also, swap/paging I/O would not involve
consolidation. It would be odd for the new consolidation to make
much of a difference for this activity. (gcc 4.2.1 based builds were
more I/O bound in my experience.)

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?


As for my poudriere-devel use, I previously used PARALLEL_JOBS=1 but
did this activity with PARALLEL_JOBS=2 (both with ALLOW_MAKE_JOBS=yes ).
PARALLEL_JOBS=2 makes comparing individual port-build times a problem
because of competing use of the CPUs over the same time period. There
also is the issue of how I/O bound each port's build is or is not
for the context.

Using "gstat -pd" and "top -CawSores" to watch devel/gcc8 build
indicates I/O %busy is usually < 2%, even < 1%, and much of the time
is 0.0% or 0.1%. (This is during a "prev-gcc" bootstrap stage, no
longer using clang.)  It would be odd for the new consolidation to
make much of an overall difference here. A more I/O bound port build?


Note: I mount with -o noatime in use.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)