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.
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 !safe_to_background() it's in our interest to let it run in
order to free up the resource that it's holding.
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.
It's more than just stopping them end up in the expired array. It's
stopping them being permanently in the expired array.
There's little difference between a background task acquiring a mutex,
and a normal task with one tick left on it's slice.
The difference is that the background task could stay there forever.
Best for sleepers
is of course to just say no to expiring mutex holders period.
In spite of my comments above, I agree that not expiring mutex holders
might (emphasis on the "might") be good for overall system performance
by reducing the time for which locks are held. Giving them a whole new
time slice on the active array might be too generous though. It could
become quite complex.
Peter
--
Peter Williams [email protected]
"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 [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]
