>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/