From owner-freebsd-fs@freebsd.org Wed Sep 5 07:37:25 2018 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2096AFE6897 for ; Wed, 5 Sep 2018 07:37:25 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic309-22.consmr.mail.gq1.yahoo.com (sonic309-22.consmr.mail.gq1.yahoo.com [98.137.65.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8779675974 for ; Wed, 5 Sep 2018 07:37:24 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: fNKKAh8VM1mw2arjdvo2rn2DN2VlUNkKdIfLlaVFxyL2hz0bizyQbmuWWqx3ZzS 9Mb75B1zIl_AIWIcobKWVpthcpj7j3Gt8uE3LLwWjvVkoYW6A3_PXhn41za1xVnpHhdgAguzCtkV ZkVMihgHJs2K0QTMc0s1Cf0eLJNHUOlnFdaMMnD1SmEiskUF.FP3jfWGQ8ImJ9WTNimDDiqLS0TR IQerNO0eoEshulN5GLg_CP77fCFpc.suf4GxOT5JrcMmJyC4lm599Ib3nIFHSAu6Dzjoe9HHcQjQ RbKxd.kSia3esV1H5nVsF6uySDIkHLdFVSQrk4247CBeqduJ9uztNPkRRAD5TxdNhTPr9X9wAU4x QWa7AHQ1mMxKlqDRkUqvuCnn6wzT_PSpV2i2x3QYHzggoM1fsJnqRIe9apts3zmSfaqxHI9jX5SP 5zaG7RD8paLqFz57ke6lRE02i3MC.x6LtdV0WNbK2_mKaEGaFNarnO829NrZavnLcXI7Af4rim8o JKROvT3UBErPre8.hDmkR21yDkSk2jG2c_n3GP22aasxgDo1IrlxUARt5h9Exzx83SmUW8JIn6DD llE2mZJnOiSk6mNDyBH6W8XMggfaeqcjmYRsShSukcQm7LdcNV0OJVZPiEh5hwlxNiwpK9nN5T4D 6SDNWz_AME2ydTCl_z6BH7eSFuD63_KCOibk.ZtoV43eAM7ler4ypJw9sXd8m_31t2Eiwd3ZvC_K PRw12Q16S5uPQvvWg8J6t6pGMJ2o64K94xhDP_rZoZsGjCIj6Le9dzoFy.OJbKStAqAXdDfcsIXD WpFyRqgURBFm0G1ip37kUc7Gz74svit6bNr0TagyQL3WIGSdlolZOT_Wc6VQUnbUMHBw0_HWhmPE cfABPrzXKVjgEsDMKsq1ZFcEcZRigsujrrQUDUny6ehnNHwdTu.V2Rt1NabTZsgCSAzT3Rt2dczc uMlW82yYAy3KKVKKz09jGuxdQ1GK_FF7br0oIf3iL_3_eEheIFLqDpUSVsa8fV1sNaMyyVrwnRNd Ax.JgymSB Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Wed, 5 Sep 2018 07:37:23 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp411.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 26d886d48418080755230e2691722203; Wed, 05 Sep 2018 07:06:55 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: CFT: TRIM Consolodation on UFS/FFS filesystems From: Mark Millard In-Reply-To: <201809050520.w855KwxS083430@chez.mckusick.com> Date: Wed, 5 Sep 2018 00:06:54 -0700 Cc: bob prohaska , FreeBSD Filesystems Content-Transfer-Encoding: 7bit Message-Id: References: <201809050520.w855KwxS083430@chez.mckusick.com> To: Kirk McKusick X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2018 07:37:25 -0000 On 2018-Sep-4, at 10:20 PM, Kirk McKusick 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)