[lkml]   [2019]   [Feb]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] PM / suspend: measure the time of filesystem syncing
> I'd rather educate other developers that this may happen. dmesg
> timestamps should already make it easy to see.
> And actually... if you do "time sync" in userspace just before
> programing the RTC and suspending, this whole issue should go away.
I agree w/ you on both comments basically.

Thad said, when it comes to dmesg, readers would guess by current
implementation of the program, the two lines of pr_info and pm_pr_dbg
are controlled by compilation flags as well as printk run-level, I
think the information is enough while it is not guaranteed for this

Another reason is, months ago I worked on my community to illustrate
this odd, adding 'sync' policy in the userspace script [1] mitigated
the longer sync (issued by kernel) in suspending, however I realized
there is still rare case because the userspace sync is before the
processes freeze, the script is potentially competing w/ other high
loading tasks which means there is still a small window (sync ->
program alarm -> suspend until freeze) that could generate such odd.

Short recap this topic is trying to give a clear indication as simple
mechanism for the platform and OS developers who may concern the
suspending time w/ some sort of time constrain; given a clear metric it
allows developers to have an easier triage such hard-to-reproduce issue
shall go to virtual memory/filesystem rather than examine whether there
is longer cost on each PM sub-state along w/ the device callbacks
through a long suspending log.

Lastly, I understand this data might not so interesting to kernel
developers; somehow my role is sitting in between trying to bridge
kernel and OS developers, I fully respect reviewers' comments and


(Apologize long URL and context as reference)
 \ /
  Last update: 2019-02-12 01:41    [W:0.062 / U:11.232 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site