Martin Diehl wrote:
> [just saw this - CC-list dropped]
> 
> On Thu, 19 Feb 2004, George Anzinger wrote:
> 
> 
>>Being in process context, you can also change the priority and schedule policy 
>>as needed to fit your application, while you are rather stuck with tasklets in 
>>this regard.
> 
> 
> How would one do that correctly? Something like
> 
> read_lock_irq(&tasklist_lock);
> current->rt_priority = 0;
> current->policy = SCHED_FIFO;
> current->prio = MAX_USER_RT_PRIO - 1;
> read_unlock_irq(&tasklist_lock);
> 
> used to fail for me with SMP kernel - looks like occasional triple-fault 
> leading to the box rebooting all of the sudden. Looking into 
> kernel/sched.c suggests we might need to acquire the runqueue lock as 
> well, but this is private there. - And anyway, AFAICS it's enclosed in 
> tasklist_lock. So given we are currently running when the above code gets 
> executed, taking the tasklist_lock should be sufficient - IMHO at least 
> but reality proved me wrong.
> 
> OTOH, directly calling sys_sched_setscheduler doesn't work (without some 
> set_fs-magic at least), because it is expecting its parameters from 
> userland.

Depends on where you want to be when you do it.  From user land you would do 
exactly what the attached program does.  In SMP you would, likely, want to do 
all the tasks in the work queue (one per cpu).

 From the kernel, again calling setscheduler() is the way to go.  I am not sure 
what is in the community tree just now, but if I recall properly, the scheduler 
itself does this so, one should be able to copy that code.

Ah, yes, there it is in  migration_thread().  It calls setscheduler().


-- 
George Anzinger   george@mvista.com
High-res-timers:  http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml