Ok, these solutions are feasible but not very comfortable.
I'll explain better what I'm going to do. I'm a developer of
Barbeque OpenSource Project that is run-time resource manager. It is basically composed of a
daemon (barbeque) and a library (rtlib) linked with user applications. A user
starts a process linked with rtlib that exchanges some information with Barbeque
(e.g. it requests a performance goal). Barbeque is in charge of the assignment
of resources trying to maintain the performance goals of all applications
and predefined system requirements (e.g. temperatures and power consumption).
When processes start, Barbeque tunes several parameters at run-time: create and
set CGroups, select cpu governors and frequency, etc. In the case of a real-time
process it decides the scheduling policy, the scheduling parameters, etc.
Barbeque runs with root privileges, thus it has the CAP_SYS_NICE capability
to enforce a RT scheduling policy on applications.
The idea is to give to Barbeque the possibility to dinamically select if
enforcing mlockall() or not for RT tasks, according to the available memory
resources. I can do this using a sort of synchronization mechanism: Barbeque
sets limits of the process and signal the rtlib to execute the mlockall() or the
munlockall(), but I think it would be better to have a syscall that Barbeque can
call directly without interfering with process execution.
Yesterday I rapidly read the code of mlockall() and relative functions and I
think that in order to add a pid parameter is maybe sufficient to convert the
pid into a task struct and replace `current` with it. Probably, it will not
be so easy. Tomorrow I'm going to read the code more in details and check if
the implementation is actually easy and does not involve too much refactoring in
the present code.
Thank you,
Federico