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

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

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.

"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

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!

"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

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.

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