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
Pierre Ossman wrote:
> 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?
I don't _think_ they are guaranteed to be executed immediately after the
interrupt handler top half is complete, but they will execute before
the next return to user space (read: they will complete before user
processes run again).
> * Can tasklets be preempted?
A tasklet can get preempted by a hard interrupt, but tasklets run in
interrupt context, so don't do anything in a tasklet that can call schedule.
> * 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).
>
IIRC, a tasklet will execute once for every time tasklet_schedule is called.
HTH
Neil
--
/***************************************************
*Neil Horman
*Software Engineer
*Red Hat, Inc.
*[email protected]
*gpg keyid: 1024D / 0x92A74FA1
*http://pgp.mit.edu
***************************************************/
Neil Horman wrote:
> Pierre Ossman wrote:
>> * Can tasklets be preempted?
>
> A tasklet can get preempted by a hard interrupt, but tasklets run in
> interrupt context, so don't do anything in a tasklet that can call
> schedule.
Being preempted by hard interrupts is sort of the point of moving the
stuff to a tasklet. Just as long as other tasklets and user space cannot
preempt it.
Are there any concerns when it comes to locking and tasklets? I've tried
finding kernel-locking-HOWTO referenced in kernel-docs.txt but the link
is dead and I can't find a mirror.
Rgds
Pierre
Pierre Ossman wrote:
> Neil Horman wrote:
>
>> Pierre Ossman wrote:
>
>
>>> * Can tasklets be preempted?
>>
>>
>> A tasklet can get preempted by a hard interrupt, but tasklets run in
>> interrupt context, so don't do anything in a tasklet that can call
>> schedule.
>
>
> Being preempted by hard interrupts is sort of the point of moving the
> stuff to a tasklet. Just as long as other tasklets and user space cannot
> preempt it.
>
> Are there any concerns when it comes to locking and tasklets? I've tried
> finding kernel-locking-HOWTO referenced in kernel-docs.txt but the link
> is dead and I can't find a mirror.
>
Locking in tasklets needs to be done the same way locking in interrupt
handlers is done. The only caveat that I can think of is that in the
event that you are accessing data shared with code that runs outisde of
the tasklet, you probably need to use spin_lock_bh to disable softirqs
in the latter code. In your environment, it would typically replace the
use of spin_lock_irq[save|restore].
HTH
Neil
> Rgds
> Pierre
>
--
/***************************************************
*Neil Horman
*Software Engineer
*Red Hat, Inc.
*[email protected]
*gpg keyid: 1024D / 0x92A74FA1
*http://pgp.mit.edu
***************************************************/
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" <[email protected]>
Newsgroups: fa.linux.kernel
To: "LKML" <[email protected]>
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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
As I was digging through the functions there was one thing that struck
me. The parameter for the tasklet is of type unsigned long, not void*.
Since the parameter in most cases is a pointer this might cause problems
on 64-bit systems. Or does the kernel do some magic to map kernel memory
in the first 4 GB?
Rgds
Pierre
Pierre> As I was digging through the functions there was one thing
Pierre> that struck me. The parameter for the tasklet is of type
Pierre> unsigned long, not void*. Since the parameter in most
Pierre> cases is a pointer this might cause problems on 64-bit
Pierre> systems. Or does the kernel do some magic to map kernel
Pierre> memory in the first 4 GB?
unsigned long will be 64 bits on a 64-bit system. There are many
places in the Linux kernel where we assume that void * and long are
the same size.
- Roland
Roland Dreier wrote:
>unsigned long will be 64 bits on a 64-bit system. There are many
>places in the Linux kernel where we assume that void * and long are
>the same size.
>
> - Roland
>
>
Just out of curiosity, how do you declare a 32-bit int then? I thought
longlong would be the 64-bit int under gcc and long stay as it is.
Rgds
Pierre
Pierre> Just out of curiosity, how do you declare a 32-bit int
Pierre> then? I thought longlong would be the 64-bit int under gcc
Pierre> and long stay as it is.
int is still 32 bits on all Linux platforms (as far as I know). To
make it explicit you can use s32.
- Roland
If you want an exact size, int32_t, uint32_t, etc. are what you'd need to
use.. Typically "long" is the biggest that can be handled in single machine
instructions, though there is no guarantee of this (I think the language
standard only guarantees that long is as least as big as int and at least 32
bits).
----- Original Message -----
From: "Pierre Ossman" <[email protected]>
Newsgroups: fa.linux.kernel
To: "Roland Dreier" <[email protected]>
Cc: "LKML" <[email protected]>
Sent: Saturday, October 16, 2004 10:37 AM
Subject: Re: Tasklet usage?
> Roland Dreier wrote:
>
>>unsigned long will be 64 bits on a 64-bit system. There are many
>>places in the Linux kernel where we assume that void * and long are
>>the same size.
>>
>> - Roland
>>
> Just out of curiosity, how do you declare a 32-bit int then? I thought
> longlong would be the 64-bit int under gcc and long stay as it is.
>
> Rgds
> Pierre
>
> -
> 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/