On Wed, Jan 31, 2024, Guilherme G. Piccoli wrote: > On 31/01/2024 15:16, Guilherme G. Piccoli wrote: > > [...] > >>> And ftrace timestamps unfortunately don't help with that, it's not > >>> showing how much time the device stay suspended, so it might be > >>> confusing and both cases could appear as the same exact scenario, even > >>> if they are completely different (fail vs success cases). > >> > >> That's odd.. my assumption was the timestamps to be valid. Were you able > >> to confirm that it's the issue with the timestamps? Perhaps check if the > >> other devices in the system also wakeup at the approximately same > >> time printed in the timestamps? > >> > > > > Hi Thinh, indeed - this a bit odd right? I guess this is maybe related > > with the way kernel keeps track of clocks on suspend - despite TSC keeps > > accounting on suspend (at least for all modern x86 processors IIUC), the > > timestamps in both tracing buffer or dmesg do not reflect suspend time. > > > > Is it different in your x86 systems? Or maybe in other architectures you > > have experience with? > > > > I've done a test on Steam Deck, take a look in both attachments - seems > > to be aligned with my perception. Also checked dmesg on my Intel laptop > > (i5-6300U, with "nonstop_tsc" capability) and the timestamps do not > > reflect the time spent in S3 suspend... > > > > Just a heads-up: just noticed that on s2idle sleep, the timestamps seems > to reflect the suspended time - just tested here. But on S3/deep sleep, > they don't... > Ok. Thanks for the info. Thinh
