[haiku-gsoc] Re: [HCD]: Bfs bug #1
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: haiku-gsoc@xxxxxxxxxxxxx
- Date: Tue, 24 Jun 2008 12:05:26 +0200 CEST
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.
> > 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) - since
only a minor amount of vnodes will be busy at any time, I'm not sure
this is a good tradeoff.
> -- but anyway, we could employ the same strategy as for pages or
> caches, i.e. continue to use a flag and use a published condition
> variable.
That sounds better to me - if that proves to be a performance hog, we
can still rethink it.
> > 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.
> > 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.
Bye,
Axel.
Other related posts:
