Quoting Samuel Thibault (2014-05-05 16:55:19) > Richard Braun, le Mon 28 Apr 2014 16:55:17 +0200, a écrit : > > But it's certainly on the right path and shouldn't be far from being > > reliable (or at least, a lot more reliable than the current code).
We encountered two problems: 1. netdde kept crashing (it incorporates a statically linked version of libmachdev, and I broke libports ABI in e9687ec4ff525ae4a88314ba4ae97da770bd012f). We have to remember this for the next Hurd package. 2. dd'ing /dev/zero into a file and interrupting the operation with ctrl-c would deadlock the filesystem. This patch series assumes that the single thread servicing paging requests would never be blocked. Unfortunately, all threads use libports, which uses a single global lock. This creates opportunities for deadlocks. I've created three patches to address this problem. The first one introduces lockless reference counting. The second one uses a single hash table for the portname to object lookups (currently, a hash table per bucket is used) and protects this with a seperate lock. The third one addresses the fact that libports holds its global lock across calls to hurd_thread_cancel (which will call thread_suspend). Richard says it's okay to hold this lock, because thread_suspend is not supposed to block, and if it does, it's a kernel bug. This is well over my head. I came up with a fix, even if it's only papering over gnumach. But said fix triggers the assertion failure I mentioned earlier here. > It's an interesting alternative indeed. This however means our ext2fs > is not multithreaded any longer, which is a bit sad considered that > we'll want to go parallel in the end. > > AIUI, Justus' second patch however now allows to limit the number of > threads, since the issue I had raised with it is solved by levelling the > requests into two separate buckets. Would it make sense to just limit > the number of threads to one, so as to get the same kind of performance > benefit without losing the potential for parallelism? Just to make sure I got my idea across. With my change, a single thread would service all requests to disk pagers, another one would manage the requests to file pagers. And those requests are mostly IO-bound, and as far as I understand it our IO layer cannot acommodate concurrent operations. If so, more threads does not mean getting more work done. For all other objects, ports_manage_multithreaded is used as before. Justus