Re: Thread model (was: Ext2 superblock fault)

[olafBuddenhagen]

Hi,

On Tue, Mar 11, 2008 at 11:19:32AM +0000, Samuel Thibault wrote:
> olafBuddenhagen@gmx.net, le Tue 11 Mar 2008 04:53:45 +0100, a écrit :

> > [I] suggested a more adaptive approach: Keep track of the existing
> > threads, and if none of them makes progress in a certain amount of
> > time (say 100 ms), allow creating some more threads. But that was
> > never implemented. Also, it still might cause considerable delays in
> > some situations; and I'm not even sure it would fix all problems. (I
> > didn't fully understand the problem discussed in this thread, so I
> > don't know whether it would be fixed by that?)
> 
> The problem I was observing is when you have a sync_all which triggers
> the write of a lot of files, but unfortunately the superblock was
> paged out, so that you aren't able to start another thread to reload
> it. Whatever the thresholds you choose, with a big enough load you
> will still have the problem of resisting to creating enough threads
> for all these request, plus one for the superblock reload request.

So the problem is that a lot of requests get queued before the first one
gets very far, so that when the superblock read is finally requested, it
ends up at the end of a long queue?

(BTW, sometimes I see the filesystem apparently hanging for a pretty
long time on system reboot -- last time I waited for it to finish, it
took a minute or so. Could that be the same effect?)

In this case, obviously any thread limiting workaround will be useless.
While a sophisticated enough approach might avoid unnecessary delays, it
couldn't prevent the creation of a huge amount of threads -- resulting
in bad performance and possibly zalloc panics.

What makes me wonder is, how can it happen in the first place that so
many requests are generated before the superblock is requested during
handling of the first one? Does handling of he requests already block
temporarily for some event before the superblock read is requested, so
more requests can come in? Or is it a scheduling issue perhaps, that the
requesting thread continues running after creating a request, rather
than handling it first?...

(I once read a claim that the main reason for poor performance of async
IPC is actually bad scheduling properties. No idea whether this is true.
If it's indeed the case, it shouldn't be too hard to fix, as Mach has an
explicit handoff-scheduling call...)

-antrik-