Re: Scheduling tasklets from process context...
arun> Since tasklets are typically used for bottom half arun> processing, is it acceptable/recommended that they be arun> scheduled from a process context (say an ioctl handler)? arun> Should one try to minimize such scheduling and try to do arun> things in process context if possible, as tasklets run in arun> interrupt context? Or is the driver writer free to use the arun> tasklets at will? What is recommended here? I guess it would work to schedule a tasklet from your ioctl handler, but I don't see a good reason to do it. What are you really trying to do? Your ioctl handler runs in process context so you are free to do pretty much anything -- allocate with GFP_KERNEL, sleep, etc. If you want to return to userspace immediately but defer some work until later, it would probably make more sense to use something like schedule_work() instead of a tasklet. The main point of tasklets is that they run at a high priority, very soon after they're scheduled, so that an interrupt handler can return quickly by deferring work to a tasklet but still not add too much latency. But in your ioctl handler, if you have some high priority work, you can just do it immediately without the complication of a tasklet. - R. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Scheduling tasklets from process context...
arun Since tasklets are typically used for bottom half arun processing, is it acceptable/recommended that they be arun scheduled from a process context (say an ioctl handler)? arun Should one try to minimize such scheduling and try to do arun things in process context if possible, as tasklets run in arun interrupt context? Or is the driver writer free to use the arun tasklets at will? What is recommended here? I guess it would work to schedule a tasklet from your ioctl handler, but I don't see a good reason to do it. What are you really trying to do? Your ioctl handler runs in process context so you are free to do pretty much anything -- allocate with GFP_KERNEL, sleep, etc. If you want to return to userspace immediately but defer some work until later, it would probably make more sense to use something like schedule_work() instead of a tasklet. The main point of tasklets is that they run at a high priority, very soon after they're scheduled, so that an interrupt handler can return quickly by deferring work to a tasklet but still not add too much latency. But in your ioctl handler, if you have some high priority work, you can just do it immediately without the complication of a tasklet. - R. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Scheduling tasklets from process context...
On Wednesday 06 April 2005 04:50, you wrote: > Since tasklets are typically used for bottom half processing, is it > acceptable/recommended that they be scheduled from a process context > (say an ioctl handler)? > > Should one try to minimize such scheduling and try to do things in process > context if possible, as tasklets run in interrupt context? Or is the driver > writer free to use the tasklets at will? What is recommended here? A tasklet does not run in interrupt context, it runs as a high priority thread, that is scheduled from either user or interrupt context. The purpose is mostly to defer workloads from interrupt context, to reduce the time spent with interrupts disabled. It would make sense to defer work from userspace to a tasklet if the hardware takes an unusual amount of time to process the userspace data. Correct me if I'm wrong :) Kenneth - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Scheduling tasklets from process context...
Hi, I have a query. Since tasklets are typically used for bottom half processing, is it acceptable/recommended that they be scheduled from a process context (say an ioctl handler)? Should one try to minimize such scheduling and try to do things in process context if possible, as tasklets run in interrupt context? Or is the driver writer free to use the tasklets at will? What is recommended here? Thanks in advance, Arun. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Scheduling tasklets from process context...
Hi, I have a query. Since tasklets are typically used for bottom half processing, is it acceptable/recommended that they be scheduled from a process context (say an ioctl handler)? Should one try to minimize such scheduling and try to do things in process context if possible, as tasklets run in interrupt context? Or is the driver writer free to use the tasklets at will? What is recommended here? Thanks in advance, Arun. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Scheduling tasklets from process context...
On Wednesday 06 April 2005 04:50, you wrote: Since tasklets are typically used for bottom half processing, is it acceptable/recommended that they be scheduled from a process context (say an ioctl handler)? Should one try to minimize such scheduling and try to do things in process context if possible, as tasklets run in interrupt context? Or is the driver writer free to use the tasklets at will? What is recommended here? A tasklet does not run in interrupt context, it runs as a high priority thread, that is scheduled from either user or interrupt context. The purpose is mostly to defer workloads from interrupt context, to reduce the time spent with interrupts disabled. It would make sense to defer work from userspace to a tasklet if the hardware takes an unusual amount of time to process the userspace data. Correct me if I'm wrong :) Kenneth - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/