Messages in this thread | | | Date | Fri, 16 Apr 1999 20:05:32 +0200 (CEST) | From | Andrea Arcangeli <> | Subject | Re: [patch] Re: CPU affinity |
| |
On Fri, 16 Apr 1999, Don Fisher wrote:
>causing refresh activity. I assume at this point there are at least three >"big=>compute bound" tasks competing for cpu resources. But when the "half
Yes.
>hour" task is rescheduled, it often forgets where it was, or finds that the >correct processor was not available when it was rescheduled? It seems that the
We don't forget its old cpu, but if its preferred cpu it's _not_ the current one and it's not an _idle_ CPU, currently we are not checking if the preferred cpu could be rescheduled and we instead go to reschedule the CPU where the wakeup happened (and usually happens in an interrupt and so we are not going to reschedule more easily the preferred cpu). We could be _far_ more smart also under high load, but I am not sure how much the additional code would affect performances, for example yesterday when I reimplemented a SMP reschedule_idle I also had to add a `next' field to the schedule_data structure and I had to protect it with a spin_lock_irq(&runqueue_lock) before __schedule_tail() (plain schedule fast path) to get the information of the current task of every CPU and without race...
Currently I am doing other things. Maybe I'll play again with the scheduler in the next days...
And thanks for the report!
Andrea Arcangeli
- 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/
| |