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 <r...@redhat.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. 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
