Re: Delay in a tasklet.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux