| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Type: refactor
Change-Id: I5235bf3e9aff58af6ba2c14e8c6529c4fc9ec86c
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
Use of _vec_len() to set vector length breaks address sanitizer.
Users should use vec_set_len(), vec_inc_len(), vec_dec_len () instead.
Type: improvement
Change-Id: I441ae948771eb21c23a61f3ff9163bdad74a2cb8
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
Type: refactor
Change-Id: I077110e1a422722e20aa546a6f3224c06ab0cde5
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
Type: refactor
Change-Id: Ie67dc579e88132ddb1ee4a34cb69f96920101772
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
Change-Id: Ied34720ca5a6e6e717eea4e86003e854031b6eab
Signed-off-by: Dave Barach <dave@barachs.net>
|
|
- always use 'va_args' as pointer in all format_* functions
- u32 for all 'indent' params as it's declaration was inconsistent
Change-Id: Ic5799309a6b104c9b50fec309cba789c8da99e79
Signed-off-by: Christophe Fontaine <christophe.fontaine@enea.com>
|
|
expiry value
This commit addresses two issues:
1) Avoid refilling the timing wheel with stale timers in rare circumstances.
The timing_wheel_advance() may call advance_cpu_time_base() to update the cpu_time_base,
which is used as a starting point for 32-bit offsets of events on the timer wheel.
If the timing_wheel_advance() is not called for a longer period of time,
then advance_cpu_time_base() is called multiple times in a loop.
advance_cpu_time_base() has two parts - the first part adjusting
the base for the existing event, and the second part trying to fill
with the new events from the overflow queue, which now fit into
the 32-bit-sized time window off the new cpu_time_base.
In doing so this second part incorrectly considers the timers which
have just expired (have the time index == w->current_time_index)
to still be unexpired and places them onto the wheel instead of returning
them as expired.
For quick successive executions of timing_wheel_advance() these events
result in a relatively benign late expiry - the newly placed events expire
during the next call to timing_wheel_advance().
If the successive executions of timing_wheel_advance() result in multiple
invocations of advance_cpu_time_base(), the Nth iteration of it may place a stale
event on the timer wheel if the event time index equals to the current time index
(which has been previously purged), while the N+1th iteration of it will trigger
an assert violation on this stale event, resulting in a reboot.
As part of the testing, two test runs were done before and after the change.
Each of the test runs consisted of the following command:
for i in `seq 1 300`; do ./test_timing_wheel validate events 10000 synthetic-time verbose seed $i iter 10000 wait-time 2 max-time 300; done
The test runs completed identically, however they uncovered the following assert failure:
vpp/src/vppinfra/test_timing_wheel.c:225 (test_timing_wheel_main) assertion `min_next_time[0] <= tm->events[i]' fails
This assert is the second issue covered by this commit:
2) Inserting a new element may result in incorrect cached expiry value
The w->cached_min_cpu_time_on_wheel is being updated within timing_wheel_advance() every time
the elements are expired.
However, it is not touched if the new elements are inserted. Assuming current time is "T"
and the cached min cpu time is "T+X", if a new element is being inserted whose expiry time is "T+Y",
and Y is such that Y < X, then the value w->cached_min_cpu_time_on_wheel becomes incorrect
until the next expiry event, during which it is updated. The test catches this transient condition
which results in the asserts seen in the runs above.
The solution is to update the w->cached_min_cpu_time_on_wheel within timing_wheel_insert_helper()
as necessary.
Change-Id: I56a65a9a11cc2a1e0b36937a9c6d5ad10233a731
Signed-off-by: Andrew Yourtchenko <ayourtch@gmail.com>
|
|
Change-Id: I7b51f88292e057c6443b12224486f2d0c9f8ae23
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
Damjan Marion
Dave Barach
Christophe Fontaine
Andrew Yourtchenko