Dear Canon...
I try to share my thoughts..
> pid = get_pid_of_the_process_to_control ()
> while (1) {
> if (cpu_usage_of_process (pid) * 100 > total_time_since_the_start
> (pid) * percent) {
> kill (SIGSTOP, pid);
> usleep (1); usleep (1); //depend on HZ const
> kill (SIGCONT, pid);
> }
> }
from what I see here, your goal are trying to be as simple as it can to
control the runtime of process and trying not to reinvent the wheel, am
I correct?
The above solution is correct, however you need to be aware of:
You are using signals. Signals is only checked on several spots, e.g
when return from servicing interrupts. This monitoring program also
likely send the signal to non running task (this is true for
Uniprocessor machine). Your supervisor program surely must run first
before sending the signal to the target process, right? Also, your
supervisor program is eating CPU times too, so at least there will be
two tasks competing for CPU time, your target task and your supervisor
program
So, in short, there is a big chance you can't get a fine
granularity...which is luckily..you already aware of it
My suggestion...try to check scheduler_tick() on kernel/sched.c. Hack
the code especially ones that calculate how much time slice is left. Of
course you will need someway to pass the pid of the task you want to
control. In this case, create a /proc entry that is related to a kernel
variable. This variable, shall we say "target_pid", can be used inside
the scheduler_tick() ..perhaps using something like:
if (current->pid = target_pid) {
if (current->counter exceeds certain time interval)
current->need_resched=1 /* it will trigger reschedule */
}
if you want "higher" level of experiment...try to google for "Bossa
scheduler". I never use it by myself, but it is kinda of scheduler
which has capabilities to receive hints from userspace. IMHO this is
useful for experiments, e.g tuning the policy without the need of
frequent recompilation.
I hope this idea is useful for you. The final decision is yours.
regards
Mulyadi
--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive: http://mail.nl.linux.org/kernelnewbies/
FAQ: http://kernelnewbies.org/faq/
