Re: [GIT PULL] adaptive spinning mutexes

[Ingo Molnar <mingo@elte.hu>]

* 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