bug-hurd
[Top][All Lists]
Advanced

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

Re: Why is it so damn slow ?


From: Richard Braun
Subject: Re: Why is it so damn slow ?
Date: Sun, 2 Dec 2012 11:15:08 +0100
User-agent: Mutt/1.5.20 (2009-06-14)

On Sat, Dec 01, 2012 at 12:53:30PM +0100, Thomas Schwinge wrote:
> So, switching to a SSD does give a small performance boost, but not the
> big one we had hoped for.  Using --no-atime improves this further.
> Perhaps we should follow suit with the Linux kernel, and implement and
> make default a Ā»relatimeĀ« mount option.

Yes, we should probably make relatime the default. Concerning the much
less than expected performance boost, I don't consider it surprising.
Last summer (while working on the VM cache, select with a timeout and
the port to pthreads), I noticed that much of the time spent by the CPU
is actually wasted for two major reasons.

One is the way the VM cache works, i.e. caching memory objects instead
of their backing pages, with a fixed limit (Mach can actually have
cached objects with no single page in memory !), but I think this reason
is now well known. The other is less obvious : the Hurd uses a lot of
spin locks, some global and heavily used such as _ports_lock in
libports. These spin locks are a plague because, once the number of
threads is significant (a number that varies with the raw performance of
the hardware), they will make servers spend much time checking the lock
state and invoking the scheduler, which is then unable to make any more
good decisions because all those threads are running. Worse, before
switching to another thread, the caller depresses its priority, so in
the end, there can be cases like the one you reported a few days ago, of
servers that, at some point (under load), have hundreds or even
thousands of threads spinning with a very low priority. Let's not even
mention fairness.

The patch I wrote which increases the priority of privileged server
threads helps, but is just an ugly hack. In my opinion, spin locks
should be completely replaced with mutexes, as a first, easy step. Then,
Mach should provide something similar to futexes. Optionally, making
the scheduler scalable would be a good thing to do, but using mutexes
will make most threads asleep, so it won't matter as much for the common
case of only a few running threads at the same time.

-- 
Richard Braun



reply via email to

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