Tasklet usage?

Tasklet usage?

[Pierre Ossman]

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

Re: Tasklet usage?

[Neil Horman]

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.
  *nhorman@redhat.com
  *gpg keyid: 1024D / 0x92A74FA1
  *http://pgp.mit.edu
  ***************************************************/

Re: Tasklet usage?

[Pierre Ossman]

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

Re: Tasklet usage?

[Neil Horman]

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.
  *nhorman@redhat.com
  *gpg keyid: 1024D / 0x92A74FA1
  *http://pgp.mit.edu
  ***************************************************/

Re: Tasklet usage?

[Pierre Ossman]

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

Re: Tasklet usage?

[Roland Dreier]

    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

Re: Tasklet usage?

[Pierre Ossman]

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

Re: Tasklet usage?

[Roland Dreier]

    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

Re: Tasklet usage?

[Robert Hancock]

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/ 

Re: Tasklet usage?

[Robert Hancock]

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" <drzeus-list@drzeus.cx>
Newsgroups: fa.linux.kernel
To: "Roland Dreier" <roland@topspin.com>
Cc: "LKML" <linux-kernel@vger.kernel.org>
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 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/