[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <51A0FB23.3050301@redhat.com>
Date: Sat, 25 May 2013 13:55:47 -0400
From: Rik van Riel <riel@...hat.com>
To: Manfred Spraul <manfred@...orfullife.com>
CC: LKML <linux-kernel@...r.kernel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Davidlohr Bueso <davidlohr.bueso@...com>, hhuang@...hat.com,
Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH v2] ipc/sem.c: fix lockup, restore FIFO behavior
On 05/25/2013 11:16 AM, Manfred Spraul wrote:
> The double coward solution:
> - wakeup stays FIFO
> - fast switch back to per-semaphore spinlock mode
>
> The patch
> a) fixes a lockup due to a missing restart.
> b) makes the wakeups again FIFO (as linux <= 3.0.9)
> c) tries to limit the time while in global lock mode as much
> as possible. (same as linux-3.0.10-rc1)
>
> Changes:
> - the wait-for-zero operations are moved into seperate lists. Thus they can
> be checked seperately, without rescanning the whole queue.
> - If a complex operation must sleep, then all pending change operations are
> moved into the global queue. This allows to keep everything FIFO.
> - When all complex operations have completed, the simple ops are moved
> back into the per-semaphore queues.
>
> Advantage:
> - FIFO. Dropping FIFO is a user visible change, and I'm a coward.
I am still not entirely convinced that FIFO is worthwhile,
but the code looks correct to me.
Acked-by: Rik van Riel <riel@...hat.com>
> - simpler check_restart logic.
> - Efficient handling of wait-for-zero semops, both simple and complex.
> - Fewer restarts in update_queue(), because pending wait-for-zero do not
> force a restart anymore.
>
> Other changes:
> - try_atomic_semop() also performs the semop. Thus rename the function.
>
> It passes tests with qemu, but not boot-tested due to EFI problems.
>
> Signed-off-by: Manfred Spraul <manfred@...orfullife.com>
--
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