netdev
[Top] [All Lists]

Re: gettimeofday scalability

To: P@xxxxxxxxxxxxxx
Subject: Re: gettimeofday scalability
From: Andrea Arcangeli <andrea@xxxxxxxxxx>
Date: Tue, 5 Oct 2004 20:55:53 +0200
Cc: netdev@xxxxxxxxxxx, Ingo Molnar <mingo@xxxxxxx>
In-reply-to: <4162CD76.4070204@xxxxxxxxxxxxxx>
References: <4162CD76.4070204@xxxxxxxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
User-agent: Mutt/1.5.6i
On Tue, Oct 05, 2004 at 05:36:06PM +0100, P@xxxxxxxxxxxxxx wrote:
> I've seen various gettimeofday locking speedup patches floating
> around for 2.4. There is a version from Stephen and Andrea
> that uses frlock, claiming 18%, and one from ingo that uses brlock.
> 2.6.8.1 uses seqlock, which contains the comment
> that it's not as cache friendly as brlock.

seqlock and frlock are the same thing. I don't see how the brlock can
work well given the fact you'll have to take it in write mode at every
timer irq. Maybe it works on a 2-way, sure not more than that. brlock
should be totally replaced by RCU anyways. brlock can also starve the
writer, which make it a security DoS (at least for some architecture,
there were two implementations, maybe one is safe).

> So can anyone summarise the relative merits of these locking
> mechanisms, before I start benchmarking?

frlock/seqlock (2.4/2.6 respectively) is the way to go, no write
starvation, and zero cacheline bouncing. 

upgrade to x86-64, there I implemented gettimeofday with vsyscalls which
also avoids entering exiting userspace which becomes the by far biggest
overhead after using seqlock. (speedup is tenfold or so)

Hope this helps.

<Prev in Thread] Current Thread [Next in Thread>