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

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

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