Messages in this thread | | | Date | Tue, 13 Jul 1999 23:28:28 -0700 | From | merblich <> | Subject | Re: Knowing which task is current in a CPU [ SMP ] |
| |
Hugo,
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/
| |