Thread (92 messages) 92 messages, 17 authors, 2009-01-16

Re: [GIT PULL] adaptive spinning mutexes

From: Ingo Molnar <hidden>
Date: 2009-01-14 21:41:58
Also in: linux-fsdevel, lkml

* Ingo Molnar [off-list ref] wrote:
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help