[haiku-gsoc] Re: [HCD]: Bfs bug #1
- From: Ingo Weinhold <ingo_weinhold@xxxxxx>
- To: haiku-gsoc@xxxxxxxxxxxxx
- Date: Tue, 24 Jun 2008 16:32:34 +0200
On 2008-06-24 at 12:05:26 [+0200], Axel Dörfler <axeld@xxxxxxxxxxxxxxxx>
wrote:
> Ingo Weinhold <ingo_weinhold@xxxxxx> wrote:
> > On 2008-06-23 at 12:12:59 [+0200], Axel Dörfler <axeld@xxxxxxxxxxxxxxxx>
> > > wrote:
> > > 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.
> > Maybe I don't get it, but when an I/O error occurs the respective
> > driver
> > should just report an error back (after some timeout supposedly),
> > shouldn't
> > it? When that happens the vnode will be marked unbusy again.
>
> Somewhere, a timeout should be reported - if the I/O chain gets it
> right, all the better, but I wouldn't trust on it. Especially when
> memory becomes tight, lots of unforeseen dependencies come up.
That might be a bit more involved, but I'd rather see those dependencies
fixed, than introducing timeouts in places where there really shouldn't be
any.
> > > 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.
> > I don't really think 4 bytes is that dramatic -- the structure is
> > already
> > over 60 bytes big and it's not like we have millions of vnodes
> > hanging
> > around
>
> 4 bytes isn't that much, but we keep all vnodes in memory as long as
> possible, so those 4 bytes already add up to 4 MB if you have 100000
> vnodes in memory (like after a "svn status" on the Haiku tree)
Don't let that read your old math teacher. :-)
> - since
> only a minor amount of vnodes will be busy at any time, I'm not sure
> this is a good tradeoff.
Unless I'm mistaken, only unused nodes are ever marked busy, which would
allow us to put the condition variable pointer in a union with a field not
needed in that situation (e.g. the file locking stuff).
> > > In any case, it's probably a good idea to improve the low memory
> > > handler that it will only pick clean vnodes.
> > +1
>
> Even though that smells like a flag or something again; we can't put
> them in a list or something, as we can't hold any locks.
What was the reason again for not doing the writing back and freeing in a
single loop?
> > > 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.
> > According to the low memory handler stack trace attached to the
> > ticket it
> > is in free_vnode(), sync'ing the vnode and never returns. The thread
> > isn't
> > even waiting -- it is just releasing a spinlock in start_waiting().
> > It
> > might be some sort of livelock, but definitely seems related to the
> > ide/scsi/... modules.
>
> Related yes, but the only reason something should be stuck in this
> situation is the lack of memory.
> Codepaths necessary to recover from extreme memory shortage should have
> some preallocated buffers around they can use then.
Definitely. That's just what I'm saying. :-)
CU, Ingo
Other related posts:
