I am building on one machine and running it on the other.
Build:
runcpu --action build --config xxx
Run:
runcpu --action run --config xxx --nobuild
All cases reported checksum mismatched. How do I resolve this.
Explanation
For SPEC CPU 2017, check out the config file options for runcpu. It lists two options that may be of interest that you can put in a header section: strict_rundir_verify and verify_binaries. I pasted their descriptions below.
strict_rundir_verify=[yes|no]:
When set, the tools will verify that the file contents in existing run directories match the expected checksums. Normally, this should always be on, and reportable runs will force it to be on. Turning it off might make the setup phase go a little faster while you are tuning the benchmarks.
Developer notes: setting strict_rundir_verify=no might be useful when prototyping a change to a workload or testing the effect of differing workloads. Note, though, that once you start changing your installed tree for such purposes it is easy to get lost; you might as well keep a pristine tree without modifications, and use a second tree that you convert_to_development.
verify_binaries=[yes|no]:
runcpu uses checksums to verify that executables match the config file that invokes them, and if they do not, runcpu forces a recompile. You can turn that feature off by setting verify_binaries=no.
Warning: It is strongly recommended that you keep this option at its default, yes (that is, enabled). If you disable this feature, you effectively say that you are willing to run a benchmark even if you don't know what you did or how you did it -- that is, you lack information as to how it was built!
The feature can be turned off because it may be useful to do so sometimes when debugging (for an example, see env_vars), but it should not be routinely disabled.
Since SPEC requires that you disclose how you build benchmarks, reportable runs (using the command-line switch --reportable or config file setting reportable=yes) will cause verify_binaries to be automatically enabled. For CPU 2017, this field replaces the field check_md5.
For SPEC CPU 2006, these two options also exist, but note that verify_binaries used to be called check_md5.
Example
Example. I recently built the SPEC CPU 2017 binaries, patched them (in their respective exe directories), and then performed a (non-reportable) run. To do this, I put the following in the "global options" header section of my configuration file:
#--------- Global Settings ----------------------------------------------------
...
reportable = 0
verify_binaries = 0
...
before building, patching, and running (with the --nobuild flag) the suite.
Related
The scenario outlined is this:
Someone has built the Linux kernel from source code.
That person wants to change the build configuration.
They still have all of the object files and temporary files that were produced by the previous build operation.
Given all of that, what needs to be done to rebuild as few things as possible in order to save time?
I understand that these will trigger or necessitate a complete recompilation of the source code:
Running make clean.
Running make menuconfig.
make clean is an obvious course of action to avoid to achieve the desired goal because it deletes all object files, both those that would need to be rebuilt and those that could otherwise be left alone. I don't know why make menuconfig would cause the build system to recompile everything, but I've read on here that that is what it would do.
The problem I see with not having the second avenue open to me is that if I change the configuration manually with a text editor, the options that I change might require changes in other options that depend on them (e.g., IMA_TRUSTED_KEYRING depends on SYSTEM_TRUSTED_KEYRING) and I'd be working without an interface that would automatically make those required secondary changes.
It occurred to me that invoking scripts/kconfig/mconf, the program built and launched by make menuconfig, could possibly be a solution to the problems described in the previous paragraph since it was not stated that mconf is what makes the build system recompile everything. But, it possibly could be that very program, so I do not wish to try it until I know it won't do that.
Sooooo, how does one achieve the stated objective given the stated scenario?
I am build several large set of source files (targets) using scons. Now, I would like to know if there is a metric I can use to show me:
How many targets remain to be build.
How long it will take -- this to be honest, this is probably a no-go as it is really hard to tell!
How can I do that in scons?
There is currently no progress indicator built into SCons, and it's also not trivial to provide one. The problem is, that SCons doesn't build the complete DAG first, and then starts the build...such that you'd have a total number of targets to visit that you could use as a reference (=100%).
Instead, it makes up the DAG on the go... It looks at each target, and then expands the list of its children (sources and implicit dependencies like headers) to check whether they are up-to-date. If a child has changed, it gets rebuilt by applying the same "build step" recursively.
In this way, SCons crawls itself from the list of targets, as given on the command-line (with the "." dir being the default), down the DAG...where only the parts are ever visited, that are required for (or, in other words: have a dependency to) the requested targets.
This makes it possible for SCons to handle things like "header files, generated by a program that must be compiled first" in the first go...but it also means that the total number of targets/children to get visited changes constantly.
So, a standard progress indicator would continuously climb towards the 80%-90%, just to then fall back to 50%...and I don't think this would give you the information you're really after.
Tip: If your builds are large and you don't want to wait, do incremental builds and only build the library/program you're currently doing work on ("scons lib1"). This will still take into account all dependencies, but only a fraction of the DAG has to get expanded. So, you use less memory and get faster update times...especially if you use the "interactive" mode. In a project with a 100000 C files total, the update of a single library with 500 C files takes about 1s on my machine. For more infos on this topic check out http://scons.org/wiki/WhySconsIsNotSlow .
Is there a (/an efficient) way of stripping unwanted source from the linux kernel? Would it be possible for the configurators (xconfig, menuconfig) to work?
As an example, I'm planning to create a different VFS design, which might break all the VFS-dependent kernel components. Also, working with the full kernel source (currently ~400 MB) is not desirable due to space reasons (I'm only interested in booting the system & debugging my code).
Note: I've thought about removing files, but I can't find how to remove the dependencies on them.
[edit] Note 2: Ok, I'll try again deciphering the Kbuild system.
If you don't mind the files just hanging there (which unless your hard disk is 50MB, it's usually not a problem), you can disable basically every disableable feature by configuring the kernel using it's own configuration tools.
For example, simply type
$ make menuconfig # or any other available configuration option
and start by saying no to everything you don't need. There's a LOT of stuff, so this may take some time! Read the README of the kernel. There's another option (which I don't remember the name) that starts the configuration with the minimum configuration automatically detected from your running kernel. That may make things easier.
I have to build custom kernels often enough, that it would make sense for me to have a tool which would take some a short list of approx. 50-100 configuration options and apply them over the default stock config file.
Now, I surely could just take a fresh kernel config (call make nconfig -> save the file without any changes done). Then change the corresponding options and compile the thing. But, the nconfig/menuconfig UIs perform some dependencies - automatically setting the values of depending/relative options. So, my question is:
(How) can I easily tap into the dependency resolving mechanism? What I'd ideally like to get is the following: taking a fresh .config file. applying a single change. do something to change the values of related configuration options, if there are any to be cahnged.
Thanks in advance!
I have to run a latency sensitive application and I have been asked to change the timer resolution to 1000 Hz or more. I searched on the net a bit and found pages about CONFIG_HZ etc.
However, there are what seem to be several other related settings in the file as well, so I want to be sure that I don't mess the settings up. I am posting some output here
$cat /boot/config-2.6.28-11-generic | grep HZ
# CONFIG_HZ_1000 is not set
# CONFIG_HZ_300 is not set
CONFIG_MACHZ_WDT=m
CONFIG_NO_HZ=y
CONFIG_HZ=250
# CONFIG_HZ_100 is not set
CONFIG_HZ_250=y
So does the second line, "# CONFIG_HZ_1000 is not set", mean that 1000Hz is not supported? Do I have to change just CONFIG_HZ and not CONFIG_HZ-250?
PS: I'm using the 2.6 kernel (ubuntu jaunty) on a Geode processor.
EDIT1: I ran some code from http://www.advenage.com/topics/linux-timer-interrupt-frequency.php on my desktop machine and the development machine. The code supposedly is an accurate measure of how fast a timer the system can sustain. The output was approximately 183 Hz (on the development machine). So will changing the timer be meaningful?
Don't edit .config directly, unless you're a Kbuild expert (and if you're asking this, you're not a Kbuild expert). Instead run make menuconfig or make xconfig to load the menu-based configuration system. Alternately, make config will do a line-based configuration process (where it asks you several hundred questions about what to configure - not recommended). The relevant option is under "Processor type and features" as "Timer frequency".
That said, this may not be necessary. Modern Linux can use high-resolution event timers (CONFIG_HIGH_RES_TIMERS) to acheive low-latency timers even without increasing the timer frequency. With a tickless system (CONFIG_NO_HZ) , the timer frequency has little effect at all.
On the other hand, I'm not sure what timer support Geode CPUs have. You may want to run cyclictest with various kernel configurations to see what you need to get low latency performance. The test you ran tests maximum dispatch frequency, not dispatch latency, so comparing with cyclictest results would be interesting. If you need really low latency, the CONFIG_PREEMPT_RT patchset may also be of interest.
To change the timer setting you need to recompile the kernel. Change the option in some standard menu configuration tool, rather than the text file.
/boot/config... files only tell you what is installed in the specific kernel binary. This is not a configuration file you can change.
does the second line, # CONFIG_HZ_1000 is not set, mean that 1000Hz is not supported?
When a config option is not available it's just not present in the .config file.
For instance, those kernel options:
# CONFIG_HZ_1000 is not set
# CONFIG_HZ_300 is not set
are available for you to set.
To set them, the safest is to use a menu based interface like make menuconfig.
In menuconfig, to find out the location of a given kernel config parameter, type / to open the search box.