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