Re: user-space hangs - followup
- From: "gil_hamilton@xxxxxxxxxxx" <gil_hamilton@xxxxxxxxxxx>
- Date: 8 Aug 2006 03:44:02 -0700
Dan Miller wrote:
One thing I'm finding is that we have code such as the following in many
parts of the driver:
timeout_jiffies = jiffies + jiffies_from_ms(timeout_msec) ;
while ( (rc = test_some_other_condition(device)) &&
(jiffies < timeout_jiffies ) ) {
schedule();
}
I now note that this is actually vulnerable to counter-wrapping; for
example, if timeout_jiffies gets set to (MAX_JIFFIES - 5), and
test_some_other_condition() takes more than 5 jiffies, the counter would
wrap and we'd wait awhile for the timeout to occur. (mind you, we have
an 850Mhz Celeron in our machines, so wrapping should still only take
about 8.4 minutes). Anyway, my question at this point is this:
Jiffies aren't the same as the time stamp counter, they count (in
effect) timer interrupts and their frequency is given by the HZ symbol.
Typically, this is somewhere between 100 and 1000, depending on
architecture and configuration settings. Even at 1000 jiffies a
second, it will take almost 50 days for the jiffies counter to wrap.
Although the counter could wrap and leave me in this loop for awhile, I'm
still calling schedule(), as I should. Now this will allow at least
kernel-space tasks to proceed, but what about user-space processes??
Would they end up blocked by this loop?? Or will they still get
scheduled??
Any thread not calling your driver, including user-mode threads, would
not be blocked by this code and hence should still get scheduled.
GH
.
- Follow-Ups:
- Re: user-space hangs - followup
- From: Dan Miller
- Re: user-space hangs - followup
- References:
- user-space hangs - followup
- From: Dan Miller
- user-space hangs - followup
- Prev by Date: Re: accessing internal h/w timers
- Next by Date: Re: accessing internal h/w timers
- Previous by thread: user-space hangs - followup
- Next by thread: Re: user-space hangs - followup
- Index(es):
Relevant Pages
|
