Re: [PATCH v2] ipc/sem.c: fix lockup, restore FIFO behavior

From: Davidlohr Bueso
Date: Sat May 25 2013 - 14:32:12 EST


On Sat, 2013-05-25 at 13:55 -0400, Rik van Riel wrote:
> 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.

Yep, could you please explain what benefits you see in keeping FIFO
order?

>
> Acked-by: Rik van Riel <riel@xxxxxxxxxx>
>
> > - 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.

I think this still needs a *lot* of testing - I don't have my Oracle
workload available right now, but I will definitely see how this patch
behaves on it. That said, I believe Oracle is are already quite happy
with the sem improvements.

Furthermore, this patch is way too invasive for considering it for 3.10
- I like Rik's patch better because it simply addresses the issue and
nothing more.

Thanks,
Davidlohr

--
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/