[haiku-gsoc] Re: [HCD]: Bfs bug #1

"Salvatore Benedetto" <emitrax@xxxxxxxxx> wrote:
> Anyway, I wanted to test with condition variable, but I'm not sure on
> how to proceed, despite of that
> though, I think we should hanle the error E_BUSY differently, because
> 10 seconds with our current
> scheduler, and with not I/O scheduler doesn't seem to be a good 
> choice
> on slow system like running
> on vmware is.

We might want to update the wait time if any more pages could be 
written back, but we definitely shouldn't wait forever for it to happen 
- it's not acceptable to kill the system upon an I/O error.
If you look closely to the vnode_low_memory_handler(), it will first 
try to write back the vnode's pages without making the vnode busy.
Only later it will mark the vnode busy in order to delete it -- since 
it cannot guaranty that it will get the same vnodes here, it needs to 
try to write them back again. At this point, a new (and dirty) vnode is 
obviously chosen, since otherwise it wouldn't be possible to hang 
there.
Condition variables obviously wouldn't help here, even though it might 
be worthwhile to use them instead of the busy flag. I don't really like 
that it would waste 4 more precious bytes per vnode, though.
In any case, it's probably a good idea to improve the low memory 
handler that it will only pick clean vnodes.

I can't imagine this being an IDE problem. It's much more probably a 
deadlock problem of some allocator in a low memory situation that 
causes this.

Bye,
   Axel.

Other related posts: