Thanks for looking at this. :) On Wed, May 25, 2016 at 9:33 AM, Sebastian Andrzej Siewior <bigeasy@xxxxxxxxxxxxx> wrote: > * Brian Silverman | 2016-05-16 14:05:54 [-0700]: > > Thank you for the explanation. > >>It happens when realtime (SCHED_RR/SCHED_FIFO) processes which have >>called mlockall(MCL_CURRENT | MCL_FUTURE) exit. > > Why can't the application drop the RT priority before its exit? Wouldn't > that be appropriate? If it crashes or gets killed, it doesn't have a chance to drop priority. >>One of them: >> queue_cyclictes-5298 [000] ....1.. 290.366030: remove_vma <-exit_mmap >> queue_cyclictes-5298 [000] ....1.. 290.366032: __might_sleep <-remove_vma >> queue_cyclictes-5298 [000] ....1.. 290.366033: ___might_sleep >><-__might_sleep >> queue_cyclictes-5298 [000] ....1.. 290.366035: kmem_cache_free <-remove_vma >> queue_cyclictes-5298 [000] ....1.. 290.366036: preempt_count_add >><-kmem_cache_free >> queue_cyclictes-5298 [000] ....2.. 290.366037: preempt_count_sub >><-kmem_cache_free >> queue_cyclictes-5298 [000] ....1.. 290.366039: __slab_free <-kmem_cache_free >> queue_cyclictes-5298 [000] d...1.. 290.366040: preempt_count_add >><-__slab_free >> queue_cyclictes-5298 [000] d...2.. 290.366041: preempt_count_sub >><-__slab_free >> queue_cyclictes-5298 [000] ....1.. 290.366043: kmem_cache_free: >>call_site=c0147054 ptr=ebb93cb8 > > In this trace and the others you attached, you have a preempt count of > at least one. Is this a function trace? For events I recently figure out > that the counter in event tracing is recorded wrongly [0]. So my > question here is basically is this a long preempt disable section or > not. > > [0] http://permalink.gmane.org/gmane.linux.kernel/2227774 Yes, they are function traces without that patch applied. Every single line in the file has a preempt count of at least 1. Brian -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
