From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S933652AbdCWKkw (ORCPT <rfc822;w@1wt.eu>);
        Thu, 23 Mar 2017 06:40:52 -0400
Received: from mx2.suse.de ([195.135.220.15]:46662 "EHLO mx2.suse.de"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S932748AbdCWKks (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Thu, 23 Mar 2017 06:40:48 -0400
Date: Thu, 23 Mar 2017 11:40:40 +0100
From: Petr Mladek <pmladek@suse.com>
To: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Cc: Steven Rostedt <rostedt@goodmis.org>,
        Andrew Morton <akpm@linux-foundation.org>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Peter Zijlstra <peterz@infradead.org>,
        "Rafael J . Wysocki" <rjw@rjwysocki.net>, linux-kernel@vger.kernel.org,
        Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
        Jan Kara <jack@suse.cz>
Subject: Re: [RFC][PATCH 1/4] printk: introduce printing kernel thread
Message-ID: <20170323104040.GG4008@pathway.suse.cz>
References: <20170306124554.828-1-sergey.senozhatsky@gmail.com>
 <20170306124554.828-2-sergey.senozhatsky@gmail.com>
 <20170322164058.GE4008@pathway.suse.cz>
 <20170323051242.GE2519@jagdpanzerIV.localdomain>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20170323051242.GE2519@jagdpanzerIV.localdomain>
User-Agent: Mutt/1.5.21 (2010-09-15)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Thu 2017-03-23 14:12:42, Sergey Senozhatsky wrote:
> 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--;
> > > +}
> > 
> 
> 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

Yup, allow/deny might might be better than on/off.

> 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()?"

True, sigh.

> > 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.

It is too close to "printk_thread" used on different place.
So, it confuses me :-)


> 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'.

Grr, you are right. LOGLEVEL_SHED is deferred another way.

Let me do one more attempt for a generic name. What about?

    printk_console_press();    or try_harder() or push()
    printk_console_relax();

or something like this?

Best Regards,
Petr