public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Willy TARREAU <willy@w.ods.org>
To: Davide Libenzi <davidel@xmailserver.org>
Cc: Andrew Morton <akpm@osdl.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Arjan Van de Ven <arjan@infradead.org>
Subject: Re: [patch] epoll use unlocked wqueue operations ...
Date: Sun, 4 Jun 2006 22:52:58 +0200	[thread overview]
Message-ID: <20060604205258.GA311@w.ods.org> (raw)
In-Reply-To: <Pine.LNX.4.64.0606031031030.17149@alien.or.mcafeemobile.com>

Hi Davide,

On Sat, Jun 03, 2006 at 10:35:52AM -0700, Davide Libenzi wrote:
> On Sat, 3 Jun 2006, Willy Tarreau wrote:
> 
> >Hi Davide,
> >
> >On Fri, Jun 02, 2006 at 04:28:25PM -0700, Davide Libenzi wrote:
> >>
> >>A few days ago Arjan signaled a lockdep red flag on epoll locks, and
> >>precisely between the epoll's device structure lock (->lock) and the 
> >>wait
> >>queue head lock (->lock). Like I explained in another email, and 
> >>directly
> >>to Arjan, this can't happen in reality because of the explicit check at
> >>eventpoll.c:592, that does not allow to drop an epoll fd inside the same
> >>epoll fd. Since lockdep is working on per-structure locks, it will never
> >>be able to know of policies enforced in other parts of the code. It was
> >>decided time ago of having the ability to drop epoll fds inside other
> >>epoll fds, that triggers a very trick wakeup operations (due to possibly
> >>reentrant callback-driven wakeups) handled by the ep_poll_safewake()
> >>function.
> >>While looking again at the code though, I noticed that all the 
> >>operations
> >>done on the epoll's main structure wait queue head (->wq) are already
> >>protected by the epoll lock (->lock), so that locked-style functions can
> >>be used to manipulate the ->wq member. This makes both a lock-acquire
> >>save, and lockdep happy.
> >>Running totalmess on my dual opteron for a while did not reveal any
> >>problem so far:
> >>
> >>http://www.xmailserver.org/totalmess.c
> >
> >Shouldn't we notice a tiny performance boost by avoiding those useless
> >locks, or do you consider they are not located in the fast path anyway ?
> 
> Well, we take a lock less but I can't say if it'll be measureable. The 
> test program above is not a performance thing though, just some code to 
> verify multiple threads doing waits on the same epoll fd.

OK, so I ported your patch to 2.4 (+epoll-lt-0.22) because I have some
code using it right there. At first, I thought I was observing measuring
errors, but after about 6 reboots, I seem to observe a consistent 6.5%
increase in the number of sessions/s on my fake web server on my dual
athlon. It jumps from 14350 hits/s with epoll-lt-0.22 alone to 15300 with
your patch. It seems much to me, but I'm sure I'm not dreaming (yet).

I'll send you (offlist) an update to 2.4-epoll-lt-0.22 which incorporates
this patch.

> - Davide

Cheers,
Willy


  reply	other threads:[~2006-06-04 20:53 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-06-02 23:28 [patch] epoll use unlocked wqueue operations Davide Libenzi
2006-06-03  6:04 ` Willy Tarreau
2006-06-03 17:35   ` Davide Libenzi
2006-06-04 20:52     ` Willy TARREAU [this message]
2006-06-05  1:01       ` Davide Libenzi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20060604205258.GA311@w.ods.org \
    --to=willy@w.ods.org \
    --cc=akpm@osdl.org \
    --cc=arjan@infradead.org \
    --cc=davidel@xmailserver.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox