Did you ever get you answer to:
"What does it mean "the answer is inherently out of date" ? :-)"
This means any time you ask which process is on a CPU,
by the time you get a answer, even on a MP system, the process
may no longer be on that CPU.
I would probably code at least one CPU, in a MP system,
NOT to run "RK tasks". Thus, you won't have your problem.
Why don't you do this?
Mitch
============
Hugo Varotto wrote:
>
> Hi Ove,
>
> 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/
-
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/