Re: RT throttling and suspend/resume (was Re: [PATCH] i2c: omap: revert "i2c: omap: switch to threaded IRQ support")

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On Tue, Oct 16, 2012 at 02:39:50PM -0700, Kevin Hilman wrote:
> + peterz, tglx
> 
> Felipe Balbi <balbi@xxxxxx> writes:
> 
> [...]
> 
> > The problem I see is that even though we properly return IRQ_WAKE_THREAD
> > and wake_up_process() manages to wakeup the IRQ thread (it returns 1),
> > the thread is never scheduled. To make things even worse, ouw irq thread
> > runs once, but doesn't run on a consecutive call. Here's some (rather
> > nasty) debug prints showing the problem:
> 
> [...]
> 
> >> [   88.721923] try_to_wake_up 1411
> >> [   88.725189] ===> irq_wake_thread 139: IRQ 72 wake_up_process 0
> >> [   88.731292] [sched_delayed] sched: RT throttling activated
> 
> This throttling message is the key one.
> 
> With RT throttling activated, the IRQ thread will not be run (it
> eventually will be allowed much later on, but by then, the I2C xfers
> have timed out.)
> 
> As a quick hack, the throttling can be disabled by seeting the
> sched_rt_runtime to RUNTIME_INF:
> 
>         # sysctl -w kernel.sched_rt_runtime_us=-1
> 
> and a quick test shows that things go back to working as expected.  But
> we still need to figure out why the throttling is hapenning...
> 
> So I started digging into why the RT runtime was so high, and noticed
> that time spent in suspend was being counted as RT runtime!
> 
> So spending time in suspend anywhere near sched_rt_runtime (0.95s) will
> cause the RT throttling to always be triggered, and thus prevent IRQ
> threads from running in the resume path.  Ouch.
> 
> I think I'm already in over my head in the RT runtime stuff, but
> counting the time spent in suspend as RT runtime smells like a bug to
> me. no?
> 
> Peter? Thomas?

it looks like removing console output completely (echo 0 >
/proc/sysrq-trigger) I don't see the issue anymore. Let me just run for
a few more iterations to make sure what I'm saying is correct.

-- 
balbi

Attachment: signature.asc
Description: Digital signature


[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux