mpslsi0 : Trying sleep, but thread marked as sleeping prohibited
Desai, Kashyap
Kashyap.Desai at lsi.com
Thu Feb 23 02:14:29 UTC 2012
> -----Original Message-----
> From: Chuck Swiger [mailto:cswiger at mac.com]
> Sent: Thursday, February 23, 2012 6:21 AM
> To: Desai, Kashyap
> Cc: freebsd-scsi at freebsd.org; freebsd-stable; McConnell, Stephen
> Subject: Re: mpslsi0 : Trying sleep, but thread marked as sleeping
> prohibited
>
> On Feb 22, 2012, at 4:22 PM, Desai, Kashyap wrote:
> > Just curious to know, What is a reason that thread can do blocking
> sleep but can't do unbounded sleep ?
>
> When you block, the scheduler can run other threads and only needs to
> wake up and run your thread after the blocking condition is completed.
>
> However, you don't want to busy-wait in a spin lock/mutex for any
> lengthy period of time. If your thread was allowed to do an unbounded
> sleep, especially in a fast interrupt handler context, what's going to
> wake it up? An NMI like the reset button [1]? :-)
When I started working on freebsd, first thing I noticed was ISR in freebsd are thread. (special thread). But at least not like linux where we don't have pid associate with ISR.
So In Freebsd we will have thread id for related isr routine.
Consider that fact, Even in fast interrupts handler context we should be able to sleep. (e.a pause("mps_pause", (hz/1000));)
Schedule can put thread into wait_queue and eventually when wait condition meet, thread will be wake by OS.
I mean if we can sleep in fast interrupt handler using mtx_ call, why not msleep/pause ?
Sorry if I am extending this conversation. I really appreciate kind of help from freebsd forum.!
` Kashyap
>
> Regards,
> --
> -Chuck
>
> [1]: Well, you could also call STI to permit clock interrupts or
> something else to fire an interrupt, but then your interrupt handler
> needs to be re-entrant. (And watch out for multiple nested interrupts
> blowing out the available stack space....)
More information about the freebsd-scsi
mailing list