Messages in this thread | | | Date | Thu, 17 Aug 2017 14:55:58 +0900 | From | Sergey Senozhatsky <> | Subject | Re: [RFC][PATCHv5 06/13] printk: register PM notifier |
| |
Hello Rafael,
On (08/16/17 14:58), Rafael J. Wysocki wrote: [..] > > hm, those two are interesting questions. in short - well, it might > > be. I don't want to interfere with PM by doing 'accidental' offloading > > etc., PM is too complicated already. so I'd prefer to switch to old > > printk behavior early (besides, I tend to see lockups reports more > > often when the kernel is up and running, rather than during PM events.) > > but, once again, may be it is too early and we can move emergency_mode > > switch. > > Well, that depends on what your goal is really.
to avoid any PM breakage :)
> I thought you wanted to do the offloading as far into the suspend as it > was safe to do (and analogously for resume), but now I see you want to > stop doing it as early as it makes sense. :-)
ideally yes :) but in reality I'd probably prefer to switch to emergency printk ASAP during PM. we have reports of broken PM because of offloading from Linaro (well... a long time ago, and printk kthread patch set was completely different back then).
> In that case I would call printk_emergency_begin_sync() from > dpm_prepare() and printk_emergency_end_sync() from dpm_complete().
hm, isn't it the case that dpm_prepare/dpm_complete are invoked only by hibernate path? or does suspend path (s2ram, etc.) also calls dpm_prepare/dpm_complete?
the 3 things we need to have (in PM context) for offloading: - unparked printk kthread - running scheduler - online non-boot CPUs (on a UP system, or with non-boot CPUs disabled, offloading is a bit questionable)
- hm, may be something else...
[..] > > we didn't want to spread printk_emergency_{begin, end} > > calls across the kernel. > > But this adds one invocation of each of them anyway *plus* some > extra code around those. Wouldn't it be cleaner to add those > invocations alone? [..] > I just don't see much point in using the notifier thing if you can > achieve basically the same without using it. :-)
sure, I just didn't want to mix printk internals with PM internals. that would put us in position of verifying future PM changes from printk-kthread point of view as well; and it can be quite complex, because printk offloading brings in big guns like scheduler and timekeeping. so the notifiers interface looks like a good alternative, besides those notifications happen early (and late) enough to keep us on the safe side.
well, I may be wrong.
-ss
| |