public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Robert Hancock <hancockr@shaw.ca>
To: linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: Tasklet usage?
Date: Fri, 15 Oct 2004 19:46:37 -0600	[thread overview]
Message-ID: <004b01c4b321$f9d75cf0$6601a8c0@northbrook> (raw)
In-Reply-To: fa.dvqma04.n40gos@ifi.uio.no

I recently made a similar change for what sounds like a similar piece of 
hardware (though in our case it was filling a FIFO for output purposes, 
which cannot be allowed to run empty, when we receive a FIFO-almost-empty 
interrupt from the device).

The tasklet will not necessarily get run immediately, as other tasklets may 
be pending on that CPU. You should be able to reduce the likelihood of this 
happening by using tasklet_hi_schedule instead of tasklet_schedule, that 
should put it ahead of any network, SCSI, etc. tasklets that may be pending.

Tasklets can only get interrupted by hard interrupts (which as someone 
mentioned, is pretty much the point of them).

As far as rescheduling the tasklet, I believe if the tasklet hasn't started, 
it will only execute once regardless of how many times you call 
tasklet_schedule. If it has already started running, and the tasklet gets 
scheduled, it will run again once it finishes.

Locking-wise, for any critical regions shared between the hard IRQ handler 
and either the tasklet or user context, spin_lock_irqsave is what you need. 
However, critical regions shared only between user context and the tasklet 
can use spin_lock_bh instead (which disables only bottom-halves and 
tasklets, not interrupts).


----- Original Message ----- 
From: "Pierre Ossman" <drzeus-list@drzeus.cx>
Newsgroups: fa.linux.kernel
To: "LKML" <linux-kernel@vger.kernel.org>
Sent: Friday, October 15, 2004 7:15 AM
Subject: Tasklet usage?


> My driver needs to spend a lot of time inside the interrupt handler 
> (draining a FIFO). I suspect this might cause problems blocking other 
> interrupt handlers so I was thinking about moving this into a tasklet.
> Not being to familiar with tasklets, a few questions pop up.
>
> * Will a tasklet scheduled from the interrupt handler be executed as soon 
> as interrupt handling is done?
> * Can tasklets be preempted?
> * If a tasklet gets scheduled while running, will it be executed once 
> more? (Needed if I get another FIFO interrupt while the tasklet is just 
> exiting).
>
> The FIFO is a bit small so time is of the essence. That's why this routine 
> is in the interrupt handler to begin with.
>
> Rgds
> Pierre Ossman
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/ 


       reply	other threads:[~2004-10-16  1:48 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <fa.dvqma04.n40gos@ifi.uio.no>
2004-10-16  1:46 ` Robert Hancock [this message]
     [not found] <fa.hf0cjfr.n3qt2d@ifi.uio.no>
     [not found] ` <fa.doac9ep.1ckig8r@ifi.uio.no>
2004-10-16 17:53   ` Tasklet usage? Robert Hancock
2004-10-15 13:14 Pierre Ossman
2004-10-15 13:32 ` Neil Horman
2004-10-15 13:46   ` Pierre Ossman
2004-10-15 14:09     ` Neil Horman
2004-10-16 15:17 ` Pierre Ossman
2004-10-16 16:03   ` Roland Dreier
2004-10-16 16:36     ` Pierre Ossman
2004-10-16 17:51       ` Roland Dreier

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='004b01c4b321$f9d75cf0$6601a8c0@northbrook' \
    --to=hancockr@shaw.ca \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox