lkml.org 
[lkml]   [2009]   [Dec]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [patch] f83f9ac causes tasks running at MAX_PRIO
From
Date
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



\
 
 \ /
  Last update: 2009-12-02 17:55    [W:0.053 / U:0.092 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site