>> - I also played with lockdep detection. With lglock-v0 applied >> some tests like flock02 and posix02 get considerable worse >> results. The difference between flock01 and flock02 is that >> the children of flock01 fight over one file lock versus >> the children of flock02 lock and unlock their own lock. >> My best guess is that the lockdep tracing is adding >> far more to the per child lock configuration. I didn't find >> any other explanation than this. Although I have to admit >> I can't find a good argument why this makes a difference >> between arch_spinlock_t and spinlock_t. >>
[...] > lockdep has overhead, and when you move from arch_spinlock_t to > "normal" spinlock_t's you end up with per-spinlock lockdep structures. > I wouldn't worry much about performance with lockdep enabled. That was the missing piece. Okay, that explains the performance degradation. >>> You had mentioned at one point that lglocks didn't play well with the >>> -rt kernels. What's the actual problem there? >> >> -rt kernels like to preempt everything possible. One mean to achieve >> this is by exchanging normal spinlock_t with rt_mutex. arch_spinlock_t >> does not get this treatment automatically via the lock framework. >> For this following patch is carried around: >> >> https://git.kernel.org/cgit/linux/kernel/git/rt/linux-stable-rt.git/commit/?h=v3.14-rt-rebase&id=da1cbed0dcf6ab22a4b50b0c5606271067749aef >> >> struct lglock { >> +#ifndef CONFIG_PREEMPT_RT_FULL >> arch_spinlock_t __percpu *lock; >> +#else >> + struct rt_mutex __percpu *lock; >> +#endif >> #ifdef CONFIG_DEBUG_LOCK_ALLOC >> struct lock_class_key lock_key; >> struct lockdep_map lock_dep_map; >> #endif >> }; >> >> [...] >> > > Ok. Is that approach problematic in some way? I expect that mainline wont accept such a patch :). T > I'm trying to understand the exact problem that you're > trying to solve for -rt with this effort. My aim is to rid of the -rt patches and mainline the features. This here is just my small contribution to the whole -rt effort. cheers, daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
