tasklets vs. workqueues

tasklets vs. workqueues

[Christian Kögler]

When should I use tasklets and when should I user workqueues?
What are the differences?

cu
Christian

Re: tasklets vs. workqueues

[Kristian Lyngstøl]

On Mon, Feb 16, 2004 at 08:20:31PM +0100, Christian Kögler wrote:
> When should I use tasklets and when should I user workqueues?
> What are the differences?

To quote "Linux Kernel Development" (Which I am currently reading):

Work queues defer work into a kernel thread-the work always runs in process
context. Most importantly, work queues are schedulable and can therefore sleep.

Normally, there is little decision between work queues or sotftirqs/tasklets.
If the deferred work need to sleep, work queues are used. If the deferred 
work need not sleepa, softirqs or tasklets are used.

[end quote]

Hope this helped :)

-- 
Med vennlig hilsen
Kristian Lyngstøl

Re: tasklets vs. workqueues

[George Anzinger]

Kristian Lyngstøl wrote:
> On Mon, Feb 16, 2004 at 08:20:31PM +0100, Christian Kögler wrote:
> 
>>When should I use tasklets and when should I user workqueues?
>>What are the differences?
> 
> 
> To quote "Linux Kernel Development" (Which I am currently reading):
> 
> Work queues defer work into a kernel thread-the work always runs in process
> context. Most importantly, work queues are schedulable and can therefore sleep.
> 
> Normally, there is little decision between work queues or sotftirqs/tasklets.
> If the deferred work need to sleep, work queues are used. If the deferred 
> work need not sleepa, softirqs or tasklets are used.

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.


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

Re: tasklets vs. workqueues

[George Anzinger]

[-- Attachment #1: Type: text/plain, Size: 1828 bytes --]

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

[-- Attachment #2: rt.c --]
[-- Type: text/plain, Size: 3205 bytes --]



/*
   rt - a utility to set the realtime priority and scheduling policy
*/

/* includes */
#include <stdio.h>
#include <stdlib.h>
#include <sched.h>
#include <unistd.h>
#define _GNU_LIBRARY__
#include <getopt.h>

/* defines */

#define RUNSTRING "usage:  rt [-f] [-v] prio [--] runstring  \n \
 or:   rt [-f] [-v] -p PID prio\\ \n\n \
where: prio specifies the realtime priority  \n \
       -f set scheduling policy to SCHED_FIFO \n \
       -v turns on verbose mode. \n \
       -p PID specifies an existing process to modify \n \
       runstring is a process and parameters \n \
       (use '--' if runstring contains options). \n"

#define POLICY(x)  x ? x-1 ? "SCHED_RR" : "SCHED_FIFO" : "SCHED_OTHER"

/* prototypes */
void print_usage(char *[]);

/* globals */
int verbose=0;  /* 0=none, !0=verbose */


main(int argc, char *argv[])
{
        struct sched_param prio_struct;
        int policy = -1;
        int pid = 0;
        int pidopt = 0;
        int optprobs = 0; /* problems parsing? */
        
        int  c;         /* generic single character */

        /* "standard" option parsing... */
        while ( (c=getopt(argc, argv, "+fp:v?")) != EOF)
        {
        switch (c) {
                case 'f':       /* set FIFO mode */
                        policy = SCHED_FIFO;
                        break;
                case 'p':       /* read PID */  
                        sscanf(optarg,"%d",&pid); 
                        pidopt=1;
                        break;
                case 'v':
                        verbose=1;      /* verbosity */
                        break;
                case '?':       /* help? */
                        printf("%s",RUNSTRING);
                        exit(0);
                default:        /* something went wrong */
                        optprobs=1;     /* we'll deal with this problem later */
                        break;
                }
        }

        if (optprobs) {
                fprintf(stderr,RUNSTRING);
                exit(1);
        }


        if((argc - optind) < 2-pidopt) {
                print_usage(argv);
        }

        sscanf(argv[optind], "%d", &(prio_struct.sched_priority));

        /* sanity checking... */
        if ( (prio_struct.sched_priority != 0) && (policy < 0 ) ) {
                policy=SCHED_RR;
                if (verbose)
                  printf("Defaulting sched policy to %s.\n", POLICY(policy));
        }

        if ( (prio_struct.sched_priority == 0 ) && (policy != SCHED_OTHER) ) {
                policy=SCHED_OTHER;
                fprintf(stderr,"Priority of %d implies sched policy of %s.\n",
                        prio_struct.sched_priority,  POLICY(policy)); 
        }


        policy = (prio_struct.sched_priority)? policy : SCHED_OTHER;
        if( sched_setscheduler(pid,policy,&prio_struct)){
                perror("Priority out of range");
                print_usage(argv);
        }
        if ( pid ) exit(0);
        argv+=optind;   /* adjust argv to point to the runstring */
        argv++;
        execvp(argv[0],argv);
        perror("exec failed..");
}

void print_usage(char * who[])
{
        printf("%s",RUNSTRING);
        exit (1);
}

Re: tasklets vs. workqueues

[Martin Diehl]

On Wed, 25 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
> 
> 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).

Ok, thanks - primary concern was kernelthread anyway. Sorry if I wasn't 
clear enough.

>  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().

Basically yes. Except that setscheduler is static in kernel/sched.c so one 
has to use sys_sched_setscheduler (and add some EXPORT_SYMBOL for it). And 
of course it needs the set_fs(KERNEL_DS) magic.

Thanks, I was hoping I've missed some simple "official" entry point there 
to create a SCHED_FIFO kernel thread from a module.

Martin

Re: tasklets vs. workqueues

[George Anzinger]

Martin Diehl wrote:
> On Wed, 25 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
>>
>>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).
> 
> 
> Ok, thanks - primary concern was kernelthread anyway. Sorry if I wasn't 
> clear enough.
> 
> 
>> 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().
> 
> 
> Basically yes. Except that setscheduler is static in kernel/sched.c so one 
> has to use sys_sched_setscheduler (and add some EXPORT_SYMBOL for it). And 
> of course it needs the set_fs(KERNEL_DS) magic.

I don't think it needs the set_fs(KERNEL_DS) magic if you use the internal 
setscheduler().  If it is static, that should be changed.... as well as the 
EXPORT  sigh.
-g
> 
> Thanks, I was hoping I've missed some simple "official" entry point there 
> to create a SCHED_FIFO kernel thread from a module.
> 
> Martin
> 
> 

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