Messages in this thread | | | Subject | Re: [patch] f83f9ac causes tasks running at MAX_PRIO | From | Mike Galbraith <> | Date | Wed, 02 Dec 2009 17:51:55 +0100 |
| |
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
| |