From: John H. <ha...@sg...> - 2003-01-18 19:31:19
|
Here is something else I'm wondering about. The macro: #define CAN_MIGRATE_TASK(p,rq,this_cpu) \ ((jiffies - (p)->sleep_timestamp > cache_decay_ticks) && \ !task_running(rq, p) && \ ((p)->cpus_allowed & (1UL << (this_cpu)))) seems to want to avoid migrating tasks that are "cache hot". Right? Except the p->sleep_timestamp seems inadequate for that determination. It gets updated for the currently executing process whenever schedule() sees it, but what if the predominant workload is compute-bound processes? It looks to me that a compute-bound process will only enter schedule() when its time slice expires. Doesn't that mean that load_balance() may select a cache-hot compute-bound process to migrate and ignore a process at the same priority that is frequently sleeping and awakening? Yes, I understand that the frequent sleeper-awakener will probably have a slightly higher priority, so load_balance() sees that one before the lower-priority compute-bound process. What concerns me is that for a given priority level, a compute-bound process won't have its sleep_timestamp updated very often, which means it will be a potential candidate for migration, even though it may be very cache-hot. What if CAN_MIGRATE_TASK could identify such a cache-hot process by determining the last jiffies value when schedule_tick() saw the process? John Hawkes |