Messages in this thread |  | | | Date | Thu, 06 Jul 2006 00:18:46 +1000 | | From | Peter Williams <> | | Subject | Re: [PATCH] sched: Add SCHED_BGND (background) scheduling policy |
| |
Peter Williams wrote: > Mike Galbraith wrote: >> On Wed, 2006-07-05 at 09:35 +1000, Peter Williams wrote: >> >>> @@ -3332,23 +3447,25 @@ need_resched_nonpreemptible: >>> } >>> >>> array = rq->active; >>> - if (unlikely(!array->nr_active)) { >>> - /* >>> - * Switch the active and expired arrays. >>> - */ >>> - schedstat_inc(rq, sched_switch); >>> - rq->active = rq->expired; >>> - rq->expired = array; >>> - array = rq->active; >>> - rq->expired_timestamp = 0; >>> - rq->best_expired_prio = MAX_PRIO; >>> - } >>> + if (unlikely(!array->nr_active)) >>> + array = switch_arrays(rq, MAX_PRIO); >>> >>> idx = sched_find_first_bit(array->bitmap); >>> +get_next: >>> queue = array->queue + idx; >>> next = list_entry(queue->next, struct task_struct, run_list); >>> + /* very strict backgrounding */ >>> + if (unlikely(task_in_background(next) && rq->expired->nr_active)) { >>> + int tmp = sched_find_first_bit(rq->expired->bitmap); >>> + >>> + if (likely(tmp < idx)) { >>> + array = switch_arrays(rq, idx); >>> + idx = tmp; >>> + goto get_next; >> >> Won't this potentially expire the mutex holder which you specifically >> protect in scheduler_tick() if it was preempted before being ticked? > > I don't think so as its prio value should cause task_in_background() to > fail.
Actually, you're right, a pre-emption at the wrong time could cause the prio value not to have been changed. There needs to be a safe_to_background(next) in there somewhere.
Peter -- Peter Williams pwil3058@bigpond.net.au
"Learning, n. The kind of ignorance distinguishing the studious." -- Ambrose Bierce - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |