Re: [PATCH 2/2] rseq/selftests: Add test for mm_cid compaction

[Gabriele Monaco <gmonaco@redhat.com>]

On Tue, 2025-02-18 at 09:13 +0100, Gabriele Monaco wrote:
> 
> However, I'm still not particularly fond of running stuff there at
> all.
> If a periodic task needs to run now, it preempts everything else and
> should be on its way as soon as possible. A task work is always going
> to delay this, although by a tiny bit.
> 
> Again, for now I cannot think of a better way without bringing
> workqueues into the picture, and in this specific case we have a
> valid
> workaround to reduce the latency.
> 

Been thinking about this for a while, what about getting the best from
both worlds?
MMs already have a dependency on workqueues (async_put_work) they
simply don't wildly schedule them like I was doing, essentially, the
whole periodic delayed_work thing was the issue.
Substituting what is currently a task_work with a plain work_struct (on
the mm) doesn't look too bad to me.

We still keep the mechanism to trigger and regulate its frequency and,
instead of doing it from a tick, we do it from
__rseq_handle_notify_resume.
This way we won't have it scheduled for sleeping, never running or
whatever exotic threads (which was a potential issue with the
delayed_work) but we also keep it in a preemptible context with
frequency comparable to the task_work.

Running it in a work_struct would probably make the batch scan
superfluous, since we are talking about some 30us which can run
perfectly fine in a kworker.

What do you think?

Thanks,
Gabriele