RPI3 swap experiments

[Mark Millard]

On 2018-Jul-23, at 8:53 AM, bob prohaska <fbsd at www.zefox.net> wrote:

> On Mon, Jul 23, 2018 at 12:11:19AM -0700, Mark Millard wrote:
>> 
>> 
>> On 2018-Jul-22, at 11:35 PM, bob prohaska <fbsd at www.zefox.net> wrote:
>> 
>>>> . . .
>>> There is some reason to think "newer" Sandisk Extreme devices differ, perhaps
>>> in a bad way, from older devices. The older device in my tests is model
>>> SDCZ80-064G and is simply labeled USB3.0. The newer, troublesome device
>>> is model SDCZ800-064G and is labeled Extreme Go USB 3.1. There are reports
>>> that the Extreme Go is slower, advising to buy the older devices if possible.
>>> 
>>> The USB3.1 flash drive is back in test, with the results of a j4 buildworld
>>> under r336567 at
>>> http://www.zefox.net/~fbsd/rpi3/swaptests/r336567/
>>> 
>>> The worst case results are still fairly dismal, close to a minute. All the
>>> swap was on microSD, so OOMA didn't strike and buildworld completed successfully.
>>> Near as I can tell no errors were reported on the console.
>> 
>> 
>> Rebuilds that do not rebuild the llvm materials (clang, lld, lldb, etc.) are not all that
>> comparable to ones that do. (This is visible in the time differences in the builds that
>> complete.) The llvm related build activity likely involves most of the potential
>> swapping, for example. Also: lots of I/O.
>> 
>> There can be two rebuilds of some of the llvm material. One stage with such is the
>> cross-compiler:
>> --- buildworld ---
>> make[1]: "/usr/src/Makefile.inc1" line 341: SYSTEM_COMPILER: Determined that CC=cc matches the source tree.  Not bootstrapping a cross-compiler.
>> make[1]: "/usr/src/Makefile.inc1" line 346: SYSTEM_LINKER: Determined that LD=ld matches the source tree.  Not bootstrapping a cross-linker.
>> (it was not rebuilt in the example). The other involves the build of the system llvm materials for
>> use in the (potentially) installed system, such as the system's clang.
>> 
>> Taking an environment that worked for lack of llvm related rebuilds may not
>> well indicate the result for rebuilds that would try to rebuild the llvm related
>> materials.
>> 
>> It is something to consider in what builds are compared, how they are
>> compared, and what one infers from comparisons.
>> 
> 
> The first step in the experiment is to run a cleanup script, consisting of
> 
> make -j8 cleandir > cleandir.log && make -j8 cleandir > cleandir.log && rm -rf /usr/obj/usr/src && rm *.log
> 
> Might this be insufficient to ensure a clean start? There's no obvious reason to build
> a cross compiler, since this is an RPI3 building world for itself. Is there an error in the 
> cleanup script?

My note was intended just as a caution, not as a claim of a specific bad
comparison. I did not know how you established the initial context for
the build.

If you are getting the same (re)build activity each time, then things should be
similar and comparisons easier and more reliable for such contexts.

On occasion builds that are updating the -r?????? might find CC=cc or LD=ld does
not match the source tree. Such builds would have a lot more activity and take
longer. (This seems the most likely large variation in activity given an explicit
cleanout before the build.)

I have not been doing a detailed comparison of the activity in your various
builds. I've not been checking/comparing the overall build times either (for
builds that completed).

A rule of thumb (for rebuilds that complete) on the same storage device
configuration: similar build times tend to be more directly comparable. Large
differences in build times suggest more cautious comparisons. It might also
suggest another rebuild (that would have, say, the matching source tree and
avoid the cross compiler build). Time tends to work as a rule of thumb only
for builds that complete unless similarity is confirmed for earlier stopping
points.

Of course completing a build that includes rebuilding those cross tools is
more/better evidence suggesting a good build context. Multiple rounds of
doing so: even more.

It is when a build that also built the cross tools, but that eventually
fails, that the comparisons are more complicated compared to successes
that did not build the cross tools(for example).


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