[haiku-gsoc] Re: [HCD]: Bfs bug #1
- From: "Salvatore Benedetto" <emitrax@xxxxxxxxx>
- To: haiku-gsoc@xxxxxxxxxxxxx
- Date: Mon, 23 Jun 2008 10:43:30 +0000
2008/6/23 Axel Dörfler <axeld@xxxxxxxxxxxxxxxx>:
> "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
Are you talking about the one in get_vnode? wouldn't it be better to
simply hanlde the E_BUSY error differently?
> - it's not acceptable to kill the system upon an I/O error.
I agree.
How about instead a mechanism that temporarely increases the priority
of the low memory handler along with the page writer in situation like this?
As I pointed out, I've noticed the page writer waiting for the low memory thread
to finish, but with the latest being unable to do so due to the
application that keeps
running and consuming memory (tar in this example) with an higher priority.
> 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.
Yep, I agree with that, I also mentioned it in my previous email that adding
a condition variable instead of the busy bit field would change the
size drastically.
Any other solution you can think of?
> In any case, it's probably a good idea to improve the low memory
> handler that it will only pick clean vnodes.
Trying to keep up here sorry, by clean you mean?
Regards,
--
Salvatore Benedetto (a.k.a. emitrax)
Student of Computer Engineer
University of Pisa
www.haiku-os.it
Other related posts:
