[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Thread model (was: Ext2 superblock fault)

From: olafBuddenhagen
Subject: Re: Thread model (was: Ext2 superblock fault)
Date: Wed, 19 Mar 2008 14:53:24 +0100
User-agent: Mutt/1.5.17+20080114 (2008-01-14)


On Wed, Mar 19, 2008 at 10:45:15AM +0000, Samuel Thibault wrote:
> olafBuddenhagen@gmx.net, le Tue 18 Mar 2008 11:02:43 +0100, a écrit :

> > I don't know how the syncing works, so I can't really tell what the
> > problem is. If there are blocking points before the superblock read,
> > we need to change that somehow. If the superblock read is the first
> > blocking point already, we need to change the scheduling, to make
> > sure that the request is handled -- up to the first blocking point
> > -- before returning to the requester.
> Yes, that's what I meant actually: the diskfs_sync_everything()
> function is able to trigger a lot of thread creations.

Err... Sorry, I don't understand this reply; it seems out of context...
I guess we are talking past each other :-(

> A way to have things work correctly would be by marking threads with a
> "level", i.e. diskfs_sync_everything runs at level 0, threads that it
> generates run at level 1, and threads that process their page faults
> run at level 2, etc.  Then we just need to limit the number of threads
> for a given level.  That should always permit termination of requests,
> while still limiting the number of thread to a constant times the
> maximum nesting of page faults.

Well, I considered something like that, but I think it would stilll be
more of a workaround than a real solution -- but complicated enough that
the real solution might actually be easier...


reply via email to

[Prev in Thread] Current Thread [Next in Thread]