Re: [patch] f83f9ac causes tasks running at MAX_PRIO

[Mike Galbraith <efault@gmx.de>]

On Wed, 2009-12-02 at 09:03 -0500, Steven Rostedt wrote:
> On Wed, 2009-12-02 at 12:46 +0100, Peter Zijlstra wrote:

> > Funny thing though, INIT_TASK() sets everything at MAX_PRIO-20.
> 
> Right, because the init task will fork. But once a task becomes idle, it
> should never do anything (but service interrupts).


Seems it forks _as_ the idle thread..

        /*
         * Make us the idle thread. Technically, schedule() should not be
         * called from this thread, however somewhere below it might be,
         * but because we are the idle thread, we just pick up running again
         * when this runqueue becomes "idle".
         */
        init_idle(current, smp_processor_id());

        calc_load_update = jiffies + LOAD_FREQ;

        /*
         * During early bootup we pretend to be a normal task:
         */
        current->sched_class = &fair_sched_class;

..init task becomes the idle thread in sched_init().. gets to
rest_init(), forks with prio and normal_prio now at MAX_PRIO, but
static_prio still at NICE_0.

Peter's change looks OK unless I'm missing something.  Though...

static void pull_task(struct rq *src_rq, struct task_struct *p,
                      struct rq *this_rq, int this_cpu)
{
        deactivate_task(src_rq, p, 0);
        set_task_cpu(p, this_cpu);
        activate_task(this_rq, p, 0);
        /*
         * Note that idle threads have a prio of MAX_PRIO, for this test
         * to be always true for them.
         */
        check_preempt_curr(this_rq, p, 0);
}

..we have some O(1) comments for future generations to ponder.

	-Mike