Re: [PATCH] sched: Add SCHED_BGND (background) scheduling policy

From: Peter Williams
Date: Wed Jul 05 2006 - 09:57:40 EST


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 pwil3058@xxxxxxxxxxxxxx

"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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/