Commit Graph

4 Commits

Author SHA1 Message Date
Johannes Berg e0917f8795 um: fix time travel mode
Unfortunately, my build fix for when time travel mode isn't
enabled broke time travel mode, because I forgot that we need
to use the timer time after the timer has been marked disabled,
and thus need to leave the time stored instead of zeroing it.

Fix that by splitting the inline into two, so we can call only
the _mode() one in the relevant code path.

Fixes: b482e48d29 ("um: fix build without CONFIG_UML_TIME_TRAVEL_SUPPORT")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
2019-08-23 00:39:53 +02:00
Johannes Berg b482e48d29 um: fix build without CONFIG_UML_TIME_TRAVEL_SUPPORT
When CONFIG_UML_TIME_TRAVEL_SUPPORT isn't set, the build was broken.
Fix this.

Fixes: 065038706f ("um: Support time travel mode")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
2019-07-04 09:52:18 +02:00
Johannes Berg 065038706f 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>
2019-07-02 23:27:36 +02:00
Anton Ivanov 2eb5f31bc4 um: Switch clocksource to hrtimers
UML is using an obsolete itimer call for
all timers and "polls" for kernel space timer firing
in its userspace portion resulting in a long list
of bugs and incorrect behaviour(s). It also uses
ITIMER_VIRTUAL for its timer which results in the
timer being dependent on it running and the cpu
load.

This patch fixes this by moving to posix high resolution
timers firing off CLOCK_MONOTONIC and relaying the timer
correctly to the UML userspace.

Fixes:
 - crashes when hosts suspends/resumes
 - broken userspace timers - effecive ~40Hz instead
   of what they should be. Note - this modifies skas behavior
   by no longer setting an itimer per clone(). Timer events
   are relayed instead.
 - kernel network packet scheduling disciplines
 - tcp behaviour especially under load
 - various timer related corner cases

Finally, overall responsiveness of userspace is better.

Signed-off-by: Thomas Meyer <thomas@m3y3r.de>
Signed-off-by: Anton Ivanov <aivanov@brocade.com>
[rw: massaged commit message]
Signed-off-by: Richard Weinberger <richard@nod.at>
2015-11-06 22:54:49 +01:00