* Ingo Molnar <mingo@xxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
