Date: Wed, 5 Sep 2018 00:06:54 -0700 From: Mark Millard <marklmi@yahoo.com> To: Kirk McKusick <mckusick@mckusick.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: <A751682B-6718-4E9F-87DB-2C7AA7076854@yahoo.com> In-Reply-To: <201809050520.w855KwxS083430@chez.mckusick.com> References: <201809050520.w855KwxS083430@chez.mckusick.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?A751682B-6718-4E9F-87DB-2C7AA7076854>