[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080508065645.678dda33@infradead.org>
Date: Thu, 8 May 2008 06:56:45 -0700
From: Arjan van de Ven <arjan@...radead.org>
To: Ingo Molnar <mingo@...e.hu>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
"Zhang, Yanmin" <yanmin_zhang@...ux.intel.com>,
Andi Kleen <andi@...stfloor.org>,
Matthew Wilcox <matthew@....cx>,
LKML <linux-kernel@...r.kernel.org>,
Alexander Viro <viro@....linux.org.uk>,
Andrew Morton <akpm@...ux-foundation.org>,
Thomas Gleixner <tglx@...utronix.de>,
"H. Peter Anvin" <hpa@...or.com>
Subject: Re: [patch] speed up / fix the new generic semaphore code (fix AIM7
40% regression with 2.6.26-rc1)
On Thu, 8 May 2008 14:01:30 +0200
Ingo Molnar <mingo@...e.hu> wrote:
>
> The contention comes from the following property of the new semaphore
> code: the new owner owns the semaphore exclusively, even if it is not
> running yet.
>
> So if the old owner, even if just a few instructions later, does a
> down() [lock_kernel()] again, it will be blocked and will have to
> wait on the new owner to eventually be scheduled (possibly on another
> CPU)! Or if another other task gets to lock_kernel() sooner than the
> "new owner" scheduled, it will be blocked unnecessarily and for a
> very long time when there are 2000 tasks running.
ok sounds like I like the fairness part of the new semaphores (but
obviously not the 67% performance downside; I'd expect to sacrifice a
little performance.. but this much??).
It sucks though; if this were a mutex, we could wake up the owner of
the bugger in the contented acquire path synchronously.... but these
are semaphores, and don't have an owner ;( bah bah bah
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists