From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753639AbdCWICq (ORCPT ); Thu, 23 Mar 2017 04:02:46 -0400 Received: from mail-pf0-f194.google.com ([209.85.192.194]:33871 "EHLO mail-pf0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751340AbdCWICo (ORCPT ); Thu, 23 Mar 2017 04:02:44 -0400 Date: Thu, 23 Mar 2017 14:12:42 +0900 From: Sergey Senozhatsky To: Petr Mladek Cc: Sergey Senozhatsky , Steven Rostedt , Andrew Morton , Linus Torvalds , Peter Zijlstra , "Rafael J . Wysocki" , linux-kernel@vger.kernel.org, Sergey Senozhatsky , Jan Kara Subject: Re: [RFC][PATCH 1/4] printk: introduce printing kernel thread Message-ID: <20170323051242.GE2519@jagdpanzerIV.localdomain> References: <20170306124554.828-1-sergey.senozhatsky@gmail.com> <20170306124554.828-2-sergey.senozhatsky@gmail.com> <20170322164058.GE4008@pathway.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170322164058.GE4008@pathway.suse.cz> User-Agent: Mutt/1.8.0 (2017-02-23) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On (03/22/17 17:40), Petr Mladek wrote: [..] > > +void console_printing_thread_off(void) > > +{ > > + printk_kthread_disable++; > > + barrier(); > > +} > > + > > +/* This re-enables printk_kthread offloading. */ > > +void console_printing_thread_on(void) > > +{ > > + barrier(); > > + printk_kthread_disable--; > > +} > > I really like that these functions are re-entrant. It will make > our life much easier. > > Just a small nitpicking. I would prefer to use the name > console_printk_kthread_off()/on(). I was several times confused > by "printing_thread" when searching the sources. The common > sub-string "printk_kthread" for all the related stuff would > make my life easier ;-) well, I guess I can rename it. one observation here is that those functions neither turn off nor disable printk_kthread. we mark the point after which we will not wake_up printk_kthread, but that does not mean that printk_kthread is already or soon will be inactive. it actually can be in running state. so the name console_do_not_offload_printing_to_printk_kthread_unless_its_already_running() will describe it better. :) --- overall the whole need of off()/on() sections is slightly worrisome. there are probably not so many cases when we need to forcibly avoid wake_up(printk_kthread) calls, but we don't have any checks/mechanisms to verify it (like, for example, might_sleep()). so it's case by case. > Just an idea. printk() and printk_deferred() behave the same way > when the kthread is enabled. I wonder if we should make it more > explicit by using names like: > > printk_deferred_mode_disabled++; > printk_deferred_mode_off(); > printk_deferred_mode_on(); hm, I certainly see what you meant here, but I suspect this naming may be a bit misleading - "so printk_deferred_mode_off() disables printk_deferred()?" > Also it is an already know term and a more generic name. This API > is used globally while the kthread is an implementation detail. > The offloading might be done another way in the future. yes, this is why I avoided mentioning "printk_kthread" (directly) in API naming. console_printing_thread is sort of neutral (well, sort of). not insisting that the naming is perfect, of course. > Finally, I think about using this variable instead of the ugly > LOGLEVEL_SCHED. The catch is that LOGLEVEL_SCHED forces > the deferred mode while these functions force the opposite. hm, sorry. not sure I see how we can do this. LOGLEVEL_SCHED hack is... hacky. yes. when we examine `printk_kthread_disable' we decide wether we must a) wake_up() printk_kthread or b) do console_trylock() the LOGLEVEL_SCHED thing is completely different tho. it tells us that neither of the above is safe -- both wake_up() and console_trylock() can potentially call into the scheduler. so I'm not sure we can easily replace LOGLEVEL_SCHED with `printk_kthread_disable'. -ss