Re: [GIT PULL] adaptive spinning mutexes

Ingo Molnar
2009-01-14T21:41:58Z

* Ingo Molnar <mingo@elte.hu> wrote:

> > You just disproved your own case :(
>
> how so? 80% is not enough? I also checked Fedora and it has
> SCHED_DEBUG=y in its kernel rpms.

Ubuntu has CONFIG_SCHED_DEBUG=y as well in their kernels.

> note that there's also a performance issue here: we generally _dont
> want_ a debug sysctl overhead in the mutex code or in any fastpath for
> that matter. So making it depend on SCHED_DEBUG is useful.
>
> sched_feat() features get optimized out at build time when SCHED_DEBUG
> is disabled. So it gives us the best of two worlds: the utility of
> sysctls in the SCHED_DEBUG=y, and they get compiled out in the
> !SCHED_DEBUG case.

There's a third issue as well: the toggle _is_ intentionally debug-only,
while sysctls are non-debug and we _really_ dont want feature assymetry
like that.

It will just splinter the application space: if there's significant
performance variances then apps will just go the path of least resistence:
instead of debugging the performance problems properly, the first group of
applications will be tuned for the sysctl_mutex_spin=0 case, the second
group of applications will be tuned for the sysctl_mutex_spin=1 case.

And if an enterprise distro decided to flip the default around we'd have a
real tuning mess.

/sys/debug/sched_features strikes the right kind of balance IMO: it's not
always available and it's explicitly in debugfs with no stable ABI so apps
cannot standardize on being able to tweak it, but it's convenient enough
in practice for developers to depend on it, performance analysis is easy,
etc., etc.

Ingo