Delay in a tasklet.

Delay in a tasklet.

[Bouchard, Sebastien]

Hi,

I'm in the process of writing a linux driver and I have a question in
regards to tasklet :

Is it ok to have large delay "udelay(1000);" in the tasklet?

If not, what should I do? 

Please send the answer to me personally (I'm not subscribe to the mailling
list) :

Sebastien Bouchard 
Software designer
Kontron Canada Inc. 
<mailto:sebastien.bouchard@ca.kontron.com> 
<http://www.kontron.com/> 
Corp. Tel.: (450) 430-5400 
Direct Tel.: (450) 437-4661 x2426 

Re: Delay in a tasklet.

[Davide Rossetti]

Bouchard, Sebastien wrote:

>Hi,
>
>I'm in the process of writing a linux driver and I have a question in
>regards to tasklet :
>
>Is it ok to have large delay "udelay(1000);" in the tasklet?
>
>If not, what should I do? 
>
>Please send the answer to me personally (I'm not subscribe to the mailling
>list) :
>  
>
I'd be interested in the answer as well. I have a driver which does 
udelay(100), so no 1000 but anyway, and of course I end up having the 
X86_64 kernel happily crying. I'm moving to a little state-machine to 
allow for a multi-pass approach instead of busy-polling..
regards

Re: Delay in a tasklet.

[Jan Engelhardt]

> I'd be interested in the answer as well. I have a driver which does
> udelay(100), so no 1000 but anyway, and of course I end up having the X86_64
> kernel happily crying. I'm moving to a little state-machine to allow for a
> multi-pass approach instead of busy-polling..
> regards

schedule_timeout() would come to mind.



Jan Engelhardt
-- 
No TOFU for me, please.

Re: Delay in a tasklet.

[linux-os]

On Wed, 30 Mar 2005, Davide Rossetti wrote:

> Bouchard, Sebastien wrote:
>
>> Hi,
>>
>> I'm in the process of writing a linux driver and I have a question in
>> regards to tasklet :
>>
>> Is it ok to have large delay "udelay(1000);" in the tasklet?
>>
>> If not, what should I do?
>>
>> Please send the answer to me personally (I'm not subscribe to the mailling
>> list) :
>>
>>
> I'd be interested in the answer as well. I have a driver which does
> udelay(100), so no 1000 but anyway, and of course I end up having the
> X86_64 kernel happily crying. I'm moving to a little state-machine to
> allow for a multi-pass approach instead of busy-polling..
> regards
>

Any time you are waiting with the interrupts off, you prevent
anything else from happening during that interval except,
perhaps some DMA operation previously started. This seriously
affects latency for other interrupt handlers.

If you are waiting with interrupts enabled, then you are
almost guaranteed to wait much longer than you expect because
there will most always be a higher-priority interrupt that
gets the CPU. In fact, you might have to disconnect your
network wire to be able to regain control!!

You mention the tasklet so I figure you are waiting for
something that was started as a result of an interrupt
then handed-off to a tasklet.

Even making a state-machine that gets control several times,
checks for the completed event, then returns, will not solve
the problem of such a defective hardware design because you
might not get the CPU back for several seconds! Hardware
needs to be designed so that you get an interrupt when
something completes. Failure to do this means that the
hardware design is defective and can't be used in a multi-
tasking environment running multiple applications.

Of course you could use such a defective design if you
also had some dedicated 8-bit processor to play secretary
and busy-wait on hardware. I encounter more-and-more
defective hardware designs where all the designer needed
to do was OR another bit into the interrupt pin and
everybody would be happy. Talk to the hardware designer
and see if you can't get the bit you are waiting for to
also generate an interrupt. Sometimes these people just
don't know any better and they will re-do their FPGA
in a few minutes if you bring these kinds of problems to
them. Others will just ignore "software" as a lower
form of life. In that case, document the hardware failures
and the software work-arounds necessary to make the
device "function", with the resulting trade-offs of
performance.

Cheers,
Dick Johnson
Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips).
  Notice : All mail here is now cached for review by Dictator Bush.
                  98.36% of all statistics are fiction.

Re: Delay in a tasklet.

[Mark Gross]

On Tuesday 29 March 2005 07:20, Bouchard, Sebastien wrote:
> Hi,
>
> I'm in the process of writing a linux driver and I have a question in
> regards to tasklet :
>
> Is it ok to have large delay "udelay(1000);" in the tasklet?
>
> If not, what should I do?
>

If the hardware can tolerate longer a longer or variable delays, then perhaps 
putting the work that has the large delay on a one shot timer would work?

If that doesn't cut it, then I wonder if you could structure your taskelt 
processing around a kernel thread.

Is this for 2.6 or 2.4 based kernels?

--mgross

Re: Delay in a tasklet.

[tvrtko.ursulin]

On 30/03/2005 12:50:01 linux-kernel-owner wrote:

>> I'd be interested in the answer as well. I have a driver which does
>> udelay(100), so no 1000 but anyway, and of course I end up having the 
X86_64
>> kernel happily crying. I'm moving to a little state-machine to allow 
for a
>> multi-pass approach instead of busy-polling..
>> regards
>
>schedule_timeout() would come to mind.

Not from a tasklet. ;)

I had a custom primitive some time ago which I imaginatively named 
taskletex. When scheduling a tasklet one could then specifiy a delay in 
jiffies. If zero, a normal tasklet would be scheduled and if >0 a timer 
would be added. Nothing fancy or special really, but it was useful for the 
work I was doing at that time.