The patch is fundamentally broken since I somehow lost the line calling schedule_delayed_work in task_mm_cid_work to re-schedule itself. Before sending a V2, however, I'd like to get some more insights about the requirements of this function. The current behaviour upstream is to call task_mm_cid_work for the task running after the scheduler tick. The function checks that we don't run too often for the same mm, but it seems possible that some process with short runtime would rarely run during the tick. The behaviour imposed by this patch (at least the intended one) is to run the task_mm_cid_work with the configured periodicity (plus scheduling latency) for each active mm. This behaviour seem to me more predictable, but would that even be required for rseq or is it just an overkill? In other words, was the tick chosen out of simplicity or is there some property that has to be preserved? P.S. I run the rseq self tests on both this and the previous patch (both broken) and saw no failure. Thanks, Gabriele
