Re: let's make libpager single-threaded

[Justus Winter]

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