timeslice reset is not tested for interrupt-induced swaps

[zephyrbot]

Reported by Andrew Boie:

The schedule_api test_sched_timeslice_reset code currently only evaluates two cases:

1. Cooperative context switches
2. Timeslice expiry

However there is a third case, if thread X is timeslicing, gets an interrupt which causes thread Y to be scheduled, AND Y is also timeslicing, then Y's timeslice needs to be reset. This requires modification to the interrupt handling code and is currently only implemented on ARM and X86.

Extend this test case to simulate and test this scenario.

(Imported from Jira ZEP-2232)

[zephyrbot]

by Mark Linkmeyer:

Since previously assigned to Sharron, I'm reassigning now to Chandrakala Kempanna .

[zephyrbot]

by Andrew Boie:

Please note: when you implement this, you will see that this is not implemented correctly on ARC and Xtensa (ZEP-2233, ZEP-2234)

[zephyrbot]

Related to ZEP-2234

[zephyrbot]

Related to ZEP-2233

[carlescufi]

@youvedeep do you plan on fixing this for the 1.11 timeframe? This is around end of February

[ramakrishnapallala]

@nashif can we move this to v1.13?

[nashif]

@ramakrishnapallala it is 1.13 time now, @kumarvikash1 can you please assign to someone please?

[pizi-nordic]

FYI: @pizi-nordic

[nashif]

@kumarvikash1 ping

[spoorthik]

@andrewboie @andyross: Do we still have the mentioned scenario for x86 and ARM only? Would you please provide some background on this issue with respect to current scheduling mechanisms?

[andyross]

I can't speak to existing test coverage (except that I don't remember hitting a case like this), but FWIW: in the new implementation, there is only one timeslice counter (well, strictly one per CPU). It's not owned by a thread and thus the posited edge case can't happen. It gets reset any time a new thread gets scheduled for any reason. Can't hurt to have more test cases though.

[carlescufi]

@andyross can this be closed?

[andyross]

Wow, this one is old. I'd say close it. The test_sched_timeslice_reset case in sched_api definitely tests that timeslices are reset appropriately during preemption events. That's not done via interrupt, per the request above, but I can 100% guarantee that the code path for preemption is the same in both cases.