[haiku-gsoc] Re: [HCD]: Bfs bug #1
- From: Ingo Weinhold <ingo_weinhold@xxxxxx>
- To: haiku-gsoc@xxxxxxxxxxxxx
- Date: Sat, 21 Jun 2008 21:11:50 +0200
On 2008-06-21 at 20:15:32 [+0200], Salvatore Benedetto <emitrax@xxxxxxxxx>
wrote:
> 2008/6/21 Ingo Weinhold <ingo_weinhold@xxxxxx>:
> >
> > On 2008-06-20 at 22:08:03 [+0200], Salvatore Benedetto <emitrax@xxxxxxxxx>
> > wrote:
> >> 2008/6/19 Ingo Weinhold <ingo_weinhold@xxxxxx>:
> >> >
> >> > I think, if at all, it's more likely a problem of the ide module or
> >> > related
> >> > modules. It normally shouldn't take more than 10 seconds to write back
> >> > changes to a file. Well unless the file is quite big and there are a
> >> > lot
> >> > of
> >> > cache changes... or the system doesn't have an I/O scheduler and starts
> >> > thrashing the disk in low-memory situations. So maybe nothing really
> >> > goes
> >> > wrong after all; at least nothing that wouldn't be fixed by using a
> >> > condition variable and wait indefinitely. You could try increasing the
> >> > timeout in get_vnode() (maybe to a minute?) and see if the problem
> >> > still
> >> > occurs.
> >>
> >> I increased the timeout and the problem persist. Same stack, same
> >> threads.
> >
> > Well, then it's supposedly a problem in the IDE module.
>
> I'm sure about this. I've run the same test again, and realized that
> the low memory thread,
> in one case, was actually in the run_queue with a priority of 5 (LOW),
> but couldn't get scheduled because
> the tar application, which run continuosly and has a greater priority
> (10 - NORMAL).
>
> I changed the priority of the thread (low memory) to NORMAL + 1, to
> see if something different would happened, and it
> actually crashed with a different stack trace, but the problem is
> still the same. Page writer waits for a node
> kept busy by the low memory thread.
>
> Now, I know our scheduler is not the best one, so I wouldn't exclude a
> "starvation" problem, since the tar
> application keeps running, eating all the CPU making the system
> unusable (Yep, we still need a scheduler btw!).
>
> I'm going to run another test with a greater priority for the lower thread.
Sure, you can try that. I agree though, that it sounds not that likely that
the thread is starved. Particularly since you already tested with priority
that should favor it.
> One question though, is it possible to see who is holding a semaphore?
> That is, not who created it,
> but who is holding it, because I haven't understand if the attached
> screenshot shows a deadlock or not.
Yep, the "sem" debugger command shows which thread has acquired the semaphore
last with what count. It also shows who released it last. The acquired count
is negated, if the thread already released the semaphore afterwards. I.e.
according to your screenshot, the thread has last acquired the semaphore (and
not released it since) and now tries to acquire it again. Judging from the
sources this could be OK though, since the thread is kind of a consumer
thread.
CU, Ingo
Other related posts:
