search

linux-test-project / ltp

Linux Test Project (mailing list: https://lists.linux.it/listinfo/ltp)
https://linux-test-project.readthedocs.io/
GNU General Public License v2.0
2.27k stars 1k forks source link

Refactor sched_yield01 with new API #1137

Closed ilmanzo closed 2 months ago

ilmanzo commented 4 months ago

Very simple refactoring.

Note frome the man page:

RETURN VALUE
       On success, sched_yield() returns 0.  On error, -1 is returned, and errno is set to indicate the error.

ERRORS
       In the Linux implementation, sched_yield() always succeeds.

So this test is basically an invariant assertion check.

pevik commented 3 months ago

@metan-ucw Do we need a test to a function which always succeeds?

pevik commented 2 months ago

@ilmanzo We probably take it. @metan-ucw Take it or delete the test please?

metan-ucw commented 2 months ago

@pevik well we probably need at least one test that actually calls the function, because if we do not do so, the kernel code that implements this function may end up broken and crash eventually and we wouldn't notice. So a very basic test just calls the functions and as long as that does not crash the kernel it's fine.

The point of this function is that it does not return immediately, if there are other processes that can run on the current CPU, which is actually useful with a realtime scheduling. So a real test would lock at least two process to a single CPU, set a realtime FIFO priority. Then one thread would call sched_yield() in a loop and the second would do some dummy work (for loops), this whole thing would have to run for a few scheduler slices. Then we would check if the time spend in the process that calls sched_yield() would be small enough (much smaller than the other process) and pass if that was the case.

pevik commented 2 months ago

@ilmanzo Any change you would have look on this according to Cyril's comments?

ilmanzo commented 2 months ago

@metan-ucw is right and he has lots of good points. Unfortunately, my visit period is ending in a few days so I'm not sure I can deliver a quality test in a short time, and I don't want to leave half-baked stuff behind. My suggestion is maybe to keep this as "smoke test" and add an entry for a future sched_yield02 proper functional test in the work queue :)