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

[Peter Williams]

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@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/