Attention is currently required from: Anastasia Klimchuk, Brian Norris, Thomas Heijligen.

View Change

1 comment:

• File tests/udelay.c:

  • Patch Set #9, Line 41: This test could fail spuriously on a heavily-loaded system

    I see you acknowledge this already, but I just want to mention that this is definitely relevant for […]

    Since this test is mostly meant to exercise the sleep-free case (as I explained in response to Anastasia's comment on the test code), do you think it would be reasonable to maintain this assertion as-is provided we ensure the tested delay is always short enough to avoid sleeping? I'm imagining 100 microseconds as written now, or 1 less than the minimum sleep time if that is not greater than 100 microseconds.
    Otherwise I wouldn't mind removing the upper bound.

    I would expect that our time-polling loop would still be responsive enough even on a heavily-loaded CI system, unless we got unlucky and the delay fell right at the end of a quantum (causing the test to be preempted), but perhaps that would still be too common to be acceptable.

To view, visit change 81545. To unsubscribe, or for help writing mail filters, visit settings.