Re: mlockall() with pid parameter

[Federico Reghenzani <federico.reghenzani@polimi.it>]

[-- Attachment #1: Type: text/plain, Size: 4567 bytes --]

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 Open
<http://bosp.dei.polimi.it/>
Source Project <http://bosp.dei.polimi.it/> 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

2016-12-07 21:01 GMT+01:00 Vlastimil Babka <vbabka@suse.cz>:

> On 12/07/2016 05:33 PM, Federico Reghenzani wrote:
> >
> >
> > 2016-12-07 17:21 GMT+01:00 Vlastimil Babka <vbabka@suse.cz
> > <mailto:vbabka@suse.cz>>:
> >
> >     On 12/07/2016 04:39 PM, Federico Reghenzani wrote:
> >     > Hello,
> >     >
> >     > I'm working on Real-Time applications in Linux. `mlockall()` is a
> >     > typical syscall used in RT processes in order to avoid page faults.
> >     > However, the use of this syscall is strongly limited by ulimits, so
> >     > basically all RT processes that want to call `mlockall()` have to
> be
> >     > executed with root privileges.
> >
> >     Is it not possible to change the ulimits with e.g. prlimit?
> >
> >
> > Yes, but it requires a synchronization between non-root process and root
> > process.
> > Because the root process has to change the limits before the non-root
> > process executes the mlockall().
>
> Would it work if you did that between fork() and exec()? If you can
> spawn them like this, that is.
>
> > Just to provide an example, another syscall used in RT tasks is the
> > sched_setscheduler() that also suffers
> > the limitation of ulimits, but it accepts the pid so the scheduling
> > policy can be enforced by a root process to
> > any other process.
> >
> >
> >
> >     > What I would like to have is a syscall that accept a "pid", so a
> process
> >     > spawned by root would be able to enforce the memory locking to
> other
> >     > non-root processes. The prototypes would be:
> >     >
> >     > int mlockall(int flags, pid_t pid);
> >     > int munlockall(pid_t pid);
> >     >
> >     > I checked the source code and it seems to me quite easy to add this
> >     > syscall variant.
> >     >
> >     > I'm writing here to have a feedback before starting to edit the
> code. Do
> >     > you think that this is a good approach?
> >     >
> >     >
> >     > Thank you,
> >     > Federico
> >     >
> >     > --
> >     > *Federico Reghenzani*
> >     > PhD Candidate
> >     > Politecnico di Milano
> >     > Dipartimento di Elettronica, Informazione e Bioingegneria
> >     >
> >
> >
> >
> >
> > --
> > *Federico Reghenzani*
> > PhD Candidate
> > Politecnico di Milano
> > Dipartimento di Elettronica, Informazione e Bioingegneria
> >
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
>



-- 
*Federico Reghenzani*
PhD Candidate
Politecnico di Milano
Dipartimento di Elettronica, Informazione e Bioingegneria

[-- Attachment #2: Type: text/html, Size: 6553 bytes --]