Peter Zijlstra <peterz@xxxxxxxxxxxxx> writes: > On Fri, 2012-10-19 at 16:54 -0700, Kevin Hilman wrote: > >> So I did the same thing for my ARM SoC, and it definitley stops the RT >> throttling. >> >> However, it has the undesriable (IMO) side effect of making timed printk >> output rather unhelpful for debugging suspend/resume since printk time >> stays constant throughout suspend/resume no matter how long you >> sleep. :( >> >> So does that mean we have to choose between useful printk times during >> suspend/resume or functioning IRQ threads during suspend/resume ? > > Urgh.. this was not something I considered. This being primarily the > sched_clock infrastructure and such. > > So what exactly is the problem with the suspend resume thing (its not > something I've ever debugged), is all you need a clean break between pre > and post suspend, or do you need the actual time the machine was gone? I think it's more a question of what people are used to. I think folks used to debugging suspend/resume (at least on ARM) are used to having the printk timestamps reflect the amount of time the machine was gone. With a sched_clock() that counts during suspend, that feature doesn't work anymore. I'm not sure that this feature is a deal breaker, but it has been convenient. I see that on x86, it's already normal that printk times don't reflect time spent in suspend, so I guess ARM needs to adapt. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
