Giuseppe Massari
unread,Dec 18, 2018, 4:35:53 AM12/18/18Sign in to reply to author
Sign in to forward
You do not have permission to delete messages in this group
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to bosp-...@googlegroups.com
Dear all,
Just to inform you that a first version of the Process management
support is already available on the branch "process-support".
Therefore, you can test it by switching as follows:
[bosp $] git checkout -b process-support origin/process-support
[bosp $] git submodule update --recursive
Then to enable:
[bosp $] make menuconfig
Run-time Resource Manager
|--- Daemon Setup
| |--- Linux Resource Management
| |--- [ * ] Linux Process Management
|--- Policies
|--- Default scheduling policy (Test)
[ * ] Test
Please note that "Test" is currently the only scheduling policy doing
something with processes. So if you want to a have demo of how the
things work, this is the policy to select.
Once compiled the demo and launched the daemon, the Process Manager
needs to know what is the name of the executable related to the
process that we want to manage. To this purpose, the command interface
has been exploited, by providing the following commands:
- bq.prm.add: "to add the process to managed list (by
executable name)"
- bq.prm.remove: "to remove the process to manage list (by executable name)"
- bq.prm.setsched: "to specify the request of resources for the given process"
The "setsched" command includes to following arguments
[-n] program name
[-p] PID
[-c] number of CPU cores (or CPU quota)
[-a] number of cores from an HW accelerator or GPU
[-m] amount of memory to reserve
These arguments could be set by an external component, like the BeeR
local daemon, and exploited by a suitable policy, accordingly.
The latter can retrieve the request info by using the
GetScheduleRequestInfo() member function of the class Process.
Bests
--
Giuseppe Massari