newbie delay/sleep question - Linux

This is a discussion on newbie delay/sleep question - Linux ; I am developing a device driver that handles an interrupt. When my device driver receives the interrupt I would like to sleep for 100 microseconds and then do some other task. My problem is I may receive another interrupt within ...

+ Reply to Thread
Results 1 to 9 of 9

Thread: newbie delay/sleep question

  1. newbie delay/sleep question

    I am developing a device driver that handles an interrupt. When my
    device driver receives the interrupt I would like to sleep for 100
    microseconds and then do some other task. My problem is I may receive
    another interrupt within that 100 microseconds and the sleep I've been
    trying to do is blocking the next guy from executing on time (waiting
    for the first guy to finish sleeping).

    I've been looking at using timers, task queues, and work queues, but
    I'm not exactly sure if that's the way to go and it seems if I base my
    delay on jiffies, I will not be able to satisfy my microsecond sleep
    requirement. Any ideas?


  2. Re: newbie delay/sleep question

    cstahl3 wrote:
    > I am developing a device driver that handles an interrupt. When my
    > device driver receives the interrupt I would like to sleep for 100
    > microseconds and then do some other task. My problem is I may receive
    > another interrupt within that 100 microseconds and the sleep I've been
    > trying to do is blocking the next guy from executing on time (waiting
    > for the first guy to finish sleeping).
    >
    > I've been looking at using timers, task queues, and work queues, but
    > I'm not exactly sure if that's the way to go and it seems if I base my
    > delay on jiffies, I will not be able to satisfy my microsecond sleep
    > requirement. Any ideas?


    Jiffies are increased at every tick (kernel tick, not clock tick), so
    you usually get between 0.001 and 0.0001s granularity, depending on your
    kernel configuration.

    The most accurate clock source you can get is usually the TSC (rdtsc and
    friends). But beware of CPUs with broken TSCs (such as some Geodes).

    Greetings,
    Aaron

  3. Re: newbie delay/sleep question

    Aaron Isotton writes:

    > cstahl3 wrote:
    >> I am developing a device driver that handles an interrupt. When my
    >> device driver receives the interrupt I would like to sleep for 100
    >> microseconds and then do some other task. My problem is I may receive
    >> another interrupt within that 100 microseconds and the sleep I've been
    >> trying to do is blocking the next guy from executing on time (waiting
    >> for the first guy to finish sleeping).
    >>
    >> I've been looking at using timers, task queues, and work queues, but
    >> I'm not exactly sure if that's the way to go and it seems if I base my
    >> delay on jiffies, I will not be able to satisfy my microsecond sleep
    >> requirement. Any ideas?

    >
    > Jiffies are increased at every tick (kernel tick, not clock tick), so
    > you usually get between 0.001 and 0.0001s granularity, depending on your
    > kernel configuration.
    >
    > The most accurate clock source you can get is usually the TSC (rdtsc and
    > friends). But beware of CPUs with broken TSCs (such as some Geodes).


    This is probably a bad advise for the following reasons (excluding the
    fact that it might be broken and there's hardly a way to detect that):
    a. RDTSC is architecture specific
    [And even on IA32 it's subject to TSD restrictions in ring3]
    b. Reports clock elapsed, and you might need to figure out how that
    translates to something more meaningful (like seconds)
    c. In my experience is not reliable on SMP

    Also see: http://en.wikipedia.org/wiki/RDTSC

    --
    vale

  4. Re: newbie delay/sleep question


    malc wrote:
    > Aaron Isotton writes:
    >
    > > cstahl3 wrote:
    > >> I am developing a device driver that handles an interrupt. When my
    > >> device driver receives the interrupt I would like to sleep for 100
    > >> microseconds and then do some other task. My problem is I may receive
    > >> another interrupt within that 100 microseconds and the sleep I've been
    > >> trying to do is blocking the next guy from executing on time (waiting
    > >> for the first guy to finish sleeping).
    > >>
    > >> I've been looking at using timers, task queues, and work queues, but
    > >> I'm not exactly sure if that's the way to go and it seems if I base my
    > >> delay on jiffies, I will not be able to satisfy my microsecond sleep
    > >> requirement. Any ideas?

    > >
    > > Jiffies are increased at every tick (kernel tick, not clock tick), so
    > > you usually get between 0.001 and 0.0001s granularity, depending on your
    > > kernel configuration.
    > >
    > > The most accurate clock source you can get is usually the TSC (rdtsc and
    > > friends). But beware of CPUs with broken TSCs (such as some Geodes).

    >
    > This is probably a bad advise for the following reasons (excluding the
    > fact that it might be broken and there's hardly a way to detect that):
    > a. RDTSC is architecture specific
    > [And even on IA32 it's subject to TSD restrictions in ring3]
    > b. Reports clock elapsed, and you might need to figure out how that
    > translates to something more meaningful (like seconds)
    > c. In my experience is not reliable on SMP
    >
    > Also see: http://en.wikipedia.org/wiki/RDTSC
    >
    > --
    > vale


    I'm working on a svme181 ppc and it looks like jiffies only gives me
    millisecond granularity. Someone suggested to use sys_rt_sigtimedwait
    but I'm not sure if I could generate signals at the kernel level to
    cause a wait. I'm also not sure on how to implement a work queue or
    tasklet, or if that's the way to go for processing multiple interrupts
    coming in without blocking. I'd like all of them to process and sleep
    accordingly.


  5. Re: newbie delay/sleep question

    "cstahl3" writes:

    > malc wrote:
    >> Aaron Isotton writes:
    >>
    >> > cstahl3 wrote:
    >> >> I am developing a device driver that handles an interrupt. When my
    >> >> device driver receives the interrupt I would like to sleep for 100
    >> >> microseconds and then do some other task. My problem is I may receive
    >> >> another interrupt within that 100 microseconds and the sleep I've been
    >> >> trying to do is blocking the next guy from executing on time (waiting
    >> >> for the first guy to finish sleeping).
    >> >>
    >> >> I've been looking at using timers, task queues, and work queues, but
    >> >> I'm not exactly sure if that's the way to go and it seems if I base my
    >> >> delay on jiffies, I will not be able to satisfy my microsecond sleep
    >> >> requirement. Any ideas?


    [..snip..]

    I completely missed the fact that the orignal post implied kernel mode, sorry
    about that (only one of the points against RDTSC is affected by this though).
    I have forgotten the most serious one however:

    RDTSC is nowhere near being reliable clock source on CPUs that do
    frequency scaling.

    > I'm working on a svme181 ppc and it looks like jiffies only gives me
    > millisecond granularity. Someone suggested to use sys_rt_sigtimedwait
    > but I'm not sure if I could generate signals at the kernel level to
    > cause a wait. I'm also not sure on how to implement a work queue or
    > tasklet, or if that's the way to go for processing multiple interrupts
    > coming in without blocking. I'd like all of them to process and sleep
    > accordingly.
    >


    Perhaps http://www.linuxjournal.com/article/8144 would be of some help.

    I'm however not sure what do you really mean by: receiving an interrupt,
    sleeping after that and then doing some other task. Do you really want
    to sleep in an IRQ handler? Besides `task' is rather overloaded term.

    --
    vale

  6. Re: newbie delay/sleep question


    malc wrote:
    > "cstahl3" writes:
    >
    > > malc wrote:
    > >> Aaron Isotton writes:
    > >>
    > >> > cstahl3 wrote:
    > >> >> I am developing a device driver that handles an interrupt. When my
    > >> >> device driver receives the interrupt I would like to sleep for 100
    > >> >> microseconds and then do some other task. My problem is I may receive
    > >> >> another interrupt within that 100 microseconds and the sleep I've been
    > >> >> trying to do is blocking the next guy from executing on time (waiting
    > >> >> for the first guy to finish sleeping).
    > >> >>
    > >> >> I've been looking at using timers, task queues, and work queues, but
    > >> >> I'm not exactly sure if that's the way to go and it seems if I base my
    > >> >> delay on jiffies, I will not be able to satisfy my microsecond sleep
    > >> >> requirement. Any ideas?

    >
    > [..snip..]
    >
    > I completely missed the fact that the orignal post implied kernel mode, sorry
    > about that (only one of the points against RDTSC is affected by this though).
    > I have forgotten the most serious one however:
    >
    > RDTSC is nowhere near being reliable clock source on CPUs that do
    > frequency scaling.
    >
    > > I'm working on a svme181 ppc and it looks like jiffies only gives me
    > > millisecond granularity. Someone suggested to use sys_rt_sigtimedwait
    > > but I'm not sure if I could generate signals at the kernel level to
    > > cause a wait. I'm also not sure on how to implement a work queue or
    > > tasklet, or if that's the way to go for processing multiple interrupts
    > > coming in without blocking. I'd like all of them to process and sleep
    > > accordingly.
    > >

    >
    > Perhaps http://www.linuxjournal.com/article/8144 would be of some help.
    >
    > I'm however not sure what do you really mean by: receiving an interrupt,
    > sleeping after that and then doing some other task. Do you really want
    > to sleep in an IRQ handler? Besides `task' is rather overloaded term.
    >
    > --
    > vale


    I don't want to sleep in the irq handler, my top half is going to
    receive the interrupt and queue them up on a tasklet or work/wait queue
    of some sort (this is the part I don't understand) and in the bottom
    half, I'd like to process each of the interrupts that come in 20
    microseconds later. My problem is, I need a very small sleep/delay
    after every interrupt that I receive but I don't want to block my
    driver. I'll check out that article, thanks!


  7. Re: newbie delay/sleep question

    "cstahl3" writes:

    > malc wrote:
    >> "cstahl3" writes:
    >>
    >> > malc wrote:


    [..snip..]

    >> I'm however not sure what do you really mean by: receiving an interrupt,
    >> sleeping after that and then doing some other task. Do you really want
    >> to sleep in an IRQ handler? Besides `task' is rather overloaded term.
    >>
    >> --
    >> vale

    >
    > I don't want to sleep in the irq handler, my top half is going to
    > receive the interrupt and queue them up on a tasklet or work/wait queue
    > of some sort (this is the part I don't understand) and in the bottom
    > half, I'd like to process each of the interrupts that come in 20
    > microseconds later. My problem is, I need a very small sleep/delay
    > after every interrupt that I receive but I don't want to block my
    > driver. I'll check out that article, thanks!
    >


    First of all a disclaimer - i have no experience working on things
    like the one you describe. Now in [1] it is claimed that BHs are
    deprecated, so you might want to rethink their usage. My reading of
    your pst seem to suggest that you want to handle the same IRQ in
    different ways, i'm puzzled.

    What context do you want to do the sleeping?
    Bottom half - no idea what rules apply
    User process context - this will probably imply rescheduling and
    20us will be unattainable

    Apart from busy looping of some sort[2] i don't think there's a solution
    with granularity you want

    [1] http://people.netfilter.org/~rusty/u...-softirqs.html
    [2] Something from `asm/delay.h' for instance

    --
    vale

  8. Re: newbie delay/sleep question

    In article <1166022770.332467.18590@79g2000cws.googlegroups.co m>,
    cstahl3 wrote:

    >My problem is, I need a very small sleep/delay after every
    >interrupt


    Have you looked at this need closely? Perhaps you can find
    some way around it.



  9. Re: newbie delay/sleep question

    >
    > I don't want to sleep in the irq handler, my top half is going to
    > receive the interrupt and queue them up on a tasklet or work/wait queue
    > of some sort (this is the part I don't understand) and in the bottom
    > half, I'd like to process each of the interrupts that come in 20
    > microseconds later. My problem is, I need a very small sleep/delay
    > after every interrupt that I receive but I don't want to block my
    > driver. I'll check out that article, thanks!


    It seems you different interrupts. If you return from your first ISR,
    you are aleady in the state you call "sleep". Next interrupt comes,
    your second ISR will process may be something more than first one.
    Thing is that, there is no shcdule mechanism taskquest or whatever that
    can give you 20 microseconds, unless it's a interrupt like you have
    hardware timer...


+ Reply to Thread