diff options
author | Johannes Berg <johannes.berg@intel.com> | 2019-05-27 10:34:27 +0200 |
---|---|---|
committer | Richard Weinberger <richard@nod.at> | 2019-07-02 23:27:36 +0200 |
commit | 065038706f77a56754e8f0c2556dab7e22dfe577 (patch) | |
tree | 00e8ea2389184678dab2abe1155988b8aa488aad /arch/um/configs | |
parent | c7c6f3b95303c7de5d52af56c902fcb5abe827df (diff) | |
download | linux-stable-065038706f77a56754e8f0c2556dab7e22dfe577.tar.gz linux-stable-065038706f77a56754e8f0c2556dab7e22dfe577.tar.bz2 linux-stable-065038706f77a56754e8f0c2556dab7e22dfe577.zip |
um: Support time travel mode
Sometimes it can be useful to run with "time travel" inside the
UML instance, for example for testing. For example, some tests
for the wireless subsystem and userspace are based on hwsim, a
virtual wireless adapter. Some tests can take a long time to
run because they e.g. wait for 120 seconds to elapse for some
regulatory checks. This obviously goes faster if it need not
actually wait that long, but time inside the test environment
just "bumps up" when there's nothing to do.
Add CONFIG_UML_TIME_TRAVEL_SUPPORT to enable code to support
such modes at runtime, selected on the command line:
* just "time-travel", in which time inside the UML instance
can move faster than real time, if there's nothing to do
* "time-travel=inf-cpu" in which time also moves slower and
any CPU processing takes no time at all, which allows to
implement consistent behaviour regardless of host CPU load
(or speed) or debug overhead.
An additional "time-travel-start=<seconds>" parameter is also
supported in this case to start the wall clock at this time
(in unix epoch).
With this enabled, the test mentioned above goes from a runtime
of about 140 seconds (with startup overhead and all) to being
CPU bound and finishing in 15 seconds (on my slow laptop).
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
Diffstat (limited to 'arch/um/configs')
0 files changed, 0 insertions, 0 deletions