that's exactly what I've done, I added a couple of variables in the task
struct ( is_rk_task, rk_debug, migration, etc ), and I'm doing that to
track the execution/path taken.
I was aware of the smp_send_reschedule() function, although I cannot say
that I completely/fully understand what is doing, so yes, it's a good
idea to instrument it.
However, my problem still remains, and that is, although I could send an
smp_send_reschedule() to another CPU ( so a new RK task assigned to that
CPU will be selected for execution ), I would like to do that only if
the task running in that CPU is not an RK task ( an RK task - resource
kernel task - is a higher priority task than regular timesharing
processes, and so it should preempt a running process in that CPU ). On
the other hand, if the task running in the target CPU is an RK task,
then the new RK task shouldn't preempt that task, it should enqueue
itself in the runqueue with its policy ( realtime FIFO ) and priority
raised. Hopefully, when the running RK task in the target CPU finishes
executing ( has consumed its reserved capacity ) the new task will be
selected for execution.
I haven't looked at 2.3.9, think that I'll download and take a look at
it.
Thanks,
Hugo
-- Hugo Varotto Computer Science Dept. University of Pittsburgh hvarotto@cs.pitt.edu http://www.cs.pitt.edu/FORTS
Ove Ewerlid wrote: > > Hugo Varotto wrote: > > > > I'm trying to implement a resource scheduler for multiprocessors. This > > is used for real-time tasks, and a part of it requires me to to do a > > task partition ( decide to which processor assign a task, and control > > the inherent migration of the goodness() funtion ) based on the > > requirements of the task. Sometimes I have the problem that, due to the > > characteristics/requirements of a task, I need to move it from the CPU > > that is running to another ( that's where my problem comes, 'cause it's > > possible that other task besides the idle is running at that CPU, and I > > will need to suspend it, migrate the desired task, and force a > > reschedule on that CPU ). > > Take a look into arch/XXX/kernel/smp.c at the function > smp_send_reschedule. > This (and the similar IPI functions) allows CPU X to send IPI interrupts > to CPU Y. As a warmup, write some code that instruments the IPI > interrupts. You will find that in 2.3.9 you have quite some number of > smp_send_reschedule. Notice the use of smp_send_reschedule in the > wake_up > routines. > > Tips, add your own variables to the task struct (sched.h) to mark your > processes, then write code that only deals with your processes. In this > way > you will at least get a system that boots and works until you enable > your "hacks" (using what ever means you choose to control your hacks). > > Ove >
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/