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?
The task in the expired array could also be a !safe_to_background() task
who already had a chance to run, and who's slice expired.
If it's worth protecting higher priority tasks from mutex holders ending
up in the expired array, then there's a case that should be examined.
There's little difference between a background task acquiring a mutex,
and a normal task with one tick left on it's slice. Best for sleepers
is of course to just say no to expiring mutex holders period.
-Mike
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
