| To: | Andrea Arcangeli <andrea@xxxxxxxxxx> |
|---|---|
| Subject: | Re: gettimeofday scalability |
| From: | P@xxxxxxxxxxxxxx |
| Date: | Tue, 05 Oct 2004 20:16:33 +0100 |
| Cc: | netdev@xxxxxxxxxxx, Ingo Molnar <mingo@xxxxxxx> |
| In-reply-to: | <20041005185553.GG26820@xxxxxxxxxxxxxxxxx> |
| References: | <4162CD76.4070204@xxxxxxxxxxxxxx> <20041005185553.GG26820@xxxxxxxxxxxxxxxxx> |
| Sender: | netdev-bounce@xxxxxxxxxxx |
| User-agent: | Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040124 |
Andrea Arcangeli wrote: On Tue, Oct 05, 2004 at 05:36:06PM +0100, P@xxxxxxxxxxxxxx wrote: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 writestarvation, and zero cacheline bouncing. Cheers. Perhaps the confusing comment wrt brlock at the top of seqlock.h can be changed so? 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) This is all in kernel space. However Stephen's suggestion of reading the tsc in user space may be a runner, as I just care about relative times. thanks guys! Pádraig. |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | PATCH: [SKBUFF] introduce skb_link_header_size(skb), Arnaldo Carvalho de Melo |
|---|---|
| Next by Date: | Re: gettimeofday scalability, Ingo Molnar |
| Previous by Thread: | Re: gettimeofday scalability, Andrea Arcangeli |
| Next by Thread: | Re: gettimeofday scalability, Andrea Arcangeli |
| Indexes: | [Date] [Thread] [Top] [All Lists] |