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

Peter Williams
2006-07-05T14:18:48Z

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