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

[Peter Williams <pwil3058@bigpond.net.au>]

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@bigpond.net.au

"Learning, n. The kind of ignorance distinguishing the studious."
  -- Ambrose Bierce