Re: [RFC/PATCH] FUSYN Realtime & robust mutexes for Linux, v2.3.1

[Ingo Molnar]

* Ulrich Drepper <drepper@xxxxxxxxxx> wrote:

> Andrew Morton wrote:
> 
> > How large is the slowdown, and on what workloads?
> 
> The fast path for all locking primitives etc in nptl today is entirely
> at userlevel.  Normally just a single atomic operation with a dozen
> other instructions.  With the fusyn stuff each and every locking
> operation needs a system call to register/unregister the thread as it
> locks/unlocks mutex/rwlocks/etc. [...]

actually, the way i understand the patch it is not that bad: normally
(in non-KCO mode) the fastpath locks/unlocks (uncontended locks) are
userspace-only. Non-KCO mode still gives all the priority guarantees. 
(There's also KCO mode for guaranteed-unlock-on-thread-death and for
broken architectures - but it doesnt have any real advantage other than
the slowdown.)

there's overhead in the wakeup handling and in the registration need for
non-KCO locks, but once things are up and running it should be quite
comparable to current futex costs - it's pure userspace.

so i think what would be nice is an extension of sys_futex() to
incorporate the fusyn primitives, and then a nice glibc patch to
introduce a robust mode for all the sync objects.

and if fusyn.c is fast enough then we could even try to do normal
futexes via fusyn.c - but not doing the registration/unregistration
(hence losing the priority guarantee, but still sharing much of the
codepath). This would be the most robust internal design i believe.

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