[haiku-gsoc] Re: [HCD]: Bfs bug #1
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: haiku-gsoc@xxxxxxxxxxxxx
- Date: Tue, 24 Jun 2008 20:22:49 +0200 CEST
Ingo Weinhold <ingo_weinhold@xxxxxx> wrote:
> On 2008-06-24 at 12:05:26 [+0200], Axel Dörfler <axeld@xxxxxxxxxxxxxxxx>
> > wrote:
> > 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.
Sure, feel free to do that ;-))
> > 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. :-)
Oops, so 400KB don't sound that dramatic, after all :-)
> > - 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).
Busy is only used when the vnode is created or removed - so it cannot
use locking during that time indeed. Doesn't sound too bad.
> > > > 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?
Because we need to get a reference before unlocking it (or mark it
busy), and we don't know if it get back into the unused list
afterwards. I don't really remember why I did it that way (in r22678
BTW), I guess it would be better to call a dec_vnode_ref_count()
version that simply frees the vnode when it's no longer used, or do it
manually.
> > > 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. :-)
Okay then :-)
Bye,
Axel.
Other related posts:
