linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Scheduling tasklets from process context...
@ 2005-04-06  2:50 arun.prabha
  2005-04-06  3:07 ` Kenneth Aafløy
  2005-04-06 16:46 ` Roland Dreier
  0 siblings, 2 replies; 3+ messages in thread
From: arun.prabha @ 2005-04-06  2:50 UTC (permalink / raw)
  To: linux-kernel


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.

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Scheduling tasklets from process context...
  2005-04-06  2:50 Scheduling tasklets from process context arun.prabha
@ 2005-04-06  3:07 ` Kenneth Aafløy
  2005-04-06 16:46 ` Roland Dreier
  1 sibling, 0 replies; 3+ messages in thread
From: Kenneth Aafløy @ 2005-04-06  3:07 UTC (permalink / raw)
  To: arun.prabha; +Cc: linux-kernel

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Scheduling tasklets from process context...
  2005-04-06  2:50 Scheduling tasklets from process context arun.prabha
  2005-04-06  3:07 ` Kenneth Aafløy
@ 2005-04-06 16:46 ` Roland Dreier
  1 sibling, 0 replies; 3+ messages in thread
From: Roland Dreier @ 2005-04-06 16:46 UTC (permalink / raw)
  To: arun.prabha; +Cc: linux-kernel

    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.


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2005-04-06 17:18 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-04-06  2:50 Scheduling tasklets from process context arun.prabha
2005-04-06  3:07 ` Kenneth Aafløy
2005-04-06 16:46 ` Roland Dreier

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).