[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: let's make libpager single-threaded
From: |
Justus Winter |
Subject: |
Re: let's make libpager single-threaded |
Date: |
Mon, 05 May 2014 17:23:10 +0200 |
User-agent: |
alot/0.3.4 |
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
- Re: let's make libpager single-threaded, Samuel Thibault, 2014/05/05
- Re: let's make libpager single-threaded,
Justus Winter <=
- Re: let's make libpager single-threaded, Richard Braun, 2014/05/05
- Re: let's make libpager single-threaded, Samuel Thibault, 2014/05/05
- Re: let's make libpager single-threaded, Richard Braun, 2014/05/05
- Re: let's make libpager single-threaded, Samuel Thibault, 2014/05/22
- Re: let's make libpager single-threaded, Richard Braun, 2014/05/27
- Re: let's make libpager single-threaded, Samuel Thibault, 2014/05/29
- Re: let's make libpager single-threaded, Richard Braun, 2014/05/29
- Re: let's make libpager single-threaded, Justus Winter, 2014/05/30
- Re: let's make libpager single-threaded, Richard Braun, 2014/05/30