Re: [patch] speed up / fix the new generic semaphore code (fix AIM740% regression with 2.6.26-rc1)

[Arjan van de Ven]

On Thu, 8 May 2008 14:01:30 +0200
Ingo Molnar <mingo@xxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/