Date: Tue, 4 Sep 2018 20:16:37 -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: <373CBC85-7A7C-4EEE-9A50-6AEAFEC05F63@yahoo.com> In-Reply-To: <3F4C9F6F-667A-4E71-A73F-31CF6A0E754A@yahoo.com> References: <201808240504.w7O54SPJ067702@chez.mckusick.com> <392FF90D-6D90-457B-94D2-9C4A05B46309@yahoo.com> <3F4C9F6F-667A-4E71-A73F-31CF6A0E754A@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[Some results.] On 2018-Sep-4, at 12:06 AM, Mark Millard <marklmi at yahoo.com> wrote: > [Test status update. I give some details of the > test context and complications/limitations as > well.] >=20 > On 2018-Aug-23, at 10:58 PM, Mark Millard <marklmi at yahoo.com> = wrote: >=20 >> On 2018-Aug-23, at 10:04 PM, Kirk McKusick <mckusick at mckusick.com> = wrote: >>=20 >>> So are you in a position to try out the TRIM consolidation = implementation? >>> In particular to see if it helps? >>=20 >> . . . >=20 >=20 > I finally have access to a mmcsdxc card of about the > same capacity as the on-an-adpater e.MMC that I used > to use with the Pine64+ 2GB. I've copied things over, > enabled trim on the (root) file system, and have > "vfs.ffs.dotrimcons: 1". I did a fsck_ffs -E. The > complete UFS (root) file system and the swap partition > are on the microsdxc card, no other storage devices > involved. (Swap not getting trim but the UFS file > system getting it.) >=20 > I'm doing an incremental -j4 buildworld buildkernel > in this environment, jumping from a build of -r337400 > to -r338450, but the Pine64+ 2GB is running -r338341. > The build removes old files as it goes along. We will > see how it goes. It is using "vm.pageout_oom_seq: 120". > I'm using: LDFLAGS.lld +=3D -Wl,--no-threads >=20 > I'll note that Ian Lepore reported in an exchange about > RPI3 testing: >=20 > QUOTE > Trim consolidation at the ufs layer might not have as much effect on > mmcsd as it does on other devices. The mmcsd driver has always > consolidated adjacent trim requests itself even when they arrive in = the > IO queue as a large number of small BIO_DELETE commands. It assembles > blocks of adjacent deletes until they reach the size of a full erase > block, then issue one erase command (I've never been convinced that > doing so is necessary, to me the sd spec implies you can delete > individual sectors). > END QUOTE >=20 > I've no known, good means of isolating and > comparing/contrasting the two consolidations (vs. the > combination of both). >=20 > As stands, at best I'll be able to report if I see any > failures or evidence of any bottlenecks. (Similarly for > a later poudriere-devel bulk.) >=20 > The microsdcx card tested for this is from a: >=20 > Sandisk Ultra 128GB Micro SDXC UHS-I Card with Adapter = SDSQUAR-128G-GN6MA >=20 > It has the application "A1" rating. About 2/3 of the UFS > partition is "Avail". About 5.5 GiByte of the microsdcx card > is not in any partition (but that was dd'd from the e.MCC > too and I do not know how to readily trim those areas). >=20 > Other points of context: >=20 > The Pine64+ 2GB is running a non-debug kernel (but with > symbols), as is my norm unless I'm looking into a > failure. Summary: So far, so good. The incremental -j4 buildworld buildkernel completed fine in somewhat under 13 hr 20 minutes. It included building the llvm related materials. The installkernel . . . installworld . . . reboot worked fine as well. I saw no evidence of bottlenecks or other issues. The context is now -r338450 based. The kernel has Mark Johnston's patch for reporting on long latencies in swapping I/O. They did not report anything. There were no console messages at all during the build, so nor reported I/O warnings or errors. What I saw via "gstat -pd" looked good to me, as did what I was via "top -CawSores". (An RPI3 has only 1 GiByte of RAM instead of 2 GiByte, and so has more I/O required and would be a different test than I ran.) The svnlite update for /usr/ports and the the poudriere bulk with PARALLEL_JOBS=3D2 and ALLOW_MAKE_JOBS=3Dyes has built 25 of 26 ports for its update, the last one being a devel/gcc8 full bootstrap that will likely continue for 10 to 11 hours more. After the pkg update and pkg upgrade I'll add some x11 related ports to the file that I use with -f and start another poudriere bulk, at least that is my current plan. Note: My poudriere-devel use is based on: # poudriere jail -l JAILNAME VERSION ARCH METHOD TIMESTAMP = PATH FBSDcortexA53jail 12.0-CURRENT arm64.aarch64 null 2017-10-20 00:19:15 = /usr/obj/DESTDIRs/clang-cortexA53-installworld-poud The PATH is to an installworld result from the same buildworld used for the Pine64+ 2GB's own installworld, but also with "distrib-dirs distribution DB_FROM_SRC=3D1". Also: # poudriere ports -l PORTSTREE METHOD TIMESTAMP PATH default null 2017-10-20 00:19:48 /usr/ports currently with: # svnlite info /usr/ports/ | grep "Re[plv]" Relative URL: ^/head Repository Root: svn://svn.freebsd.org/ports Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 Revision: 478753 Last Changed Rev: 478753 =3D=3D=3D 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?373CBC85-7A7C-4EEE-9A50-6AEAFEC05F63>