All of lore.kernel.org
 help / color / mirror / Atom feed
From: Roland Dreier <roland@topspin.com>
To: <arun.prabha@wipro.com>
Cc: <linux-kernel@vger.kernel.org>
Subject: Re: Scheduling tasklets from process context...
Date: Wed, 06 Apr 2005 09:46:17 -0700	[thread overview]
Message-ID: <52mzsbam5i.fsf@topspin.com> (raw)
In-Reply-To: <8F94FD7C111E3D43BA3C7CF89CB50E92012AA7B5@BLR-EC-2K3MSG.wipro.com> (arun prabha's message of "Wed, 6 Apr 2005 08:20:28 +0530")

    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.


      parent reply	other threads:[~2005-04-06 17:18 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=52mzsbam5i.fsf@topspin.com \
    --to=roland@topspin.com \
    --cc=arun.prabha@wipro.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.