From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751572AbdHQFzn (ORCPT ); Thu, 17 Aug 2017 01:55:43 -0400 Received: from mail-pg0-f65.google.com ([74.125.83.65]:36797 "EHLO mail-pg0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750800AbdHQFzm (ORCPT ); Thu, 17 Aug 2017 01:55:42 -0400 Date: Thu, 17 Aug 2017 14:55:58 +0900 From: Sergey Senozhatsky To: "Rafael J. Wysocki" Cc: Sergey Senozhatsky , Sergey Senozhatsky , Petr Mladek , Steven Rostedt , Jan Kara , Andrew Morton , Peter Zijlstra , Eric Biederman , Greg Kroah-Hartman , Jiri Slaby , Pavel Machek , Andreas Mohr , Tetsuo Handa , linux-kernel@vger.kernel.org Subject: Re: [RFC][PATCHv5 06/13] printk: register PM notifier Message-ID: <20170817055558.GC20907@jagdpanzerIV.localdomain> References: <20170815025625.1977-1-sergey.senozhatsky@gmail.com> <10043624.VvthE8rrlX@aspire.rjw.lan> <20170816073116.GB522@jagdpanzerIV.localdomain> <1933345.ycXYzBI3bM@aspire.rjw.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1933345.ycXYzBI3bM@aspire.rjw.lan> User-Agent: Mutt/1.8.3 (2017-05-23) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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