Date: Sun, 2 Sep 2018 11:57:11 -0700 From: bob prohaska <fbsd@www.zefox.net> To: Ronald Klop <ronald-lists@klop.ws> Cc: Mark Millard <marklmi@yahoo.com>, freebsd-arm@freebsd.org, bob prohaska <fbsd@www.zefox.net> Subject: Re: RPI3 swap experiments (r338342 with vm.pageout_oom_seq="1024") Message-ID: <20180902185711.GC44384@www.zefox.net> In-Reply-To: <op.zop6s4iekndu52@sjakie> References: <CANCZdfqFKY3Woa%2B9pVS5hika_JUAUCxAvLznSS4gaLq2kKoWtQ@mail.gmail.com> <20180815013612.GB51051@www.zefox.net> <CANCZdfoB_AcidFpKT_ZmZWUFnmC4Bw55krK%2BMqEmmj=f9KMQ2Q@mail.gmail.com> <20180815225504.GB59074@www.zefox.net> <20180901230233.GA42895@www.zefox.net> <F3AF3A89-322E-4048-A758-4276C1A1BEA0@yahoo.com> <20180902083217.GA44384@www.zefox.net> <6B8E28DC-075D-4829-9BEA-F36DDB1E2A25@yahoo.com> <20180902152717.GB44384@www.zefox.net> <op.zop6s4iekndu52@sjakie>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Sep 02, 2018 at 07:56:54PM +0200, Ronald Klop wrote: > On Sun, 02 Sep 2018 17:27:17 +0200, bob prohaska <fbsd@www.zefox.net> > wrote: > > > On Sun, Sep 02, 2018 at 06:57:15AM -0700, Mark Millard wrote: > >> Was this with or without (presuming a ufs file system): > >> > >> tunefs: trim: (-t) enabled > >> > >> ? If enabled, with or without: > >> > >> sysctl vfs.ffs.dotrimcons=1 > >> > >> In other words: was "consolidation of TRIM / BIO_DELETE > >> commands to the UFS/FFS filesystem" enabled? Disabled? > >> > > > > No, it was not. By all accounts TRIM enabling won't affect USB2.0 > > devices, > > and it's fairly clear the bottleneck is in USB, not microSD. Trim is > > enabled > > for mmcsd0s2a, but sysctl vfs.ffs.dotrimcons=1 hasn't been invoked. I'll > > turn > > Sysctl vfs.ffs.dotrimcons is about FFS/UFS. Not about swap. > So unless there is UFS on the same device as swap, the sysctl will not > have any effect. > In the present setup there is ufs on both mmcsd0 and da0: / is still on mmcsd0; /var/, /tmp/ and /usr/ are all on da0 and there are three swap partitions on each device, usually enabled pairwise. Usual practice is to run make cleandir twice, run rm -rf /usr/obj/usr/src once and then run -j4 buildworld. Seemingly all of the delete activity should finish before any compiler activity starts. Is that how the system really behaves? If it "saves up" deletes until something wants to write to the no-longer-needed storage space that might explain some of the congestion issues. In a few cases I've happpened upon the top window when things were going very slowly. Checking gstat's output showed initial congestion of both da0g (/usr) and swap (e.g., da0b), followed by prolonged congestion of da0g. In the same interval da0b ceased to be an obstruction, but idle times often remained about 50% in top. One should take my tale with a grain of salt, it's only casual observation, but it is suggestive. Thanks for reading! bob prohaska
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180902185711.GC44384>