From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757705AbcDABNE (ORCPT ); Thu, 31 Mar 2016 21:13:04 -0400 Received: from mail-pa0-f54.google.com ([209.85.220.54]:34034 "EHLO mail-pa0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753222AbcDABNB (ORCPT ); Thu, 31 Mar 2016 21:13:01 -0400 Date: Fri, 1 Apr 2016 10:14:28 +0900 From: Sergey Senozhatsky To: Jan Kara Cc: Sergey Senozhatsky , Andrew Morton , Jan Kara , Petr Mladek , Tejun Heo , Tetsuo Handa , linux-kernel@vger.kernel.org, Byungchul Park , Sergey Senozhatsky Subject: Re: [RFC][PATCH v8 1/2] printk: Make printk() completely async Message-ID: <20160401011428.GB501@swordfish> References: <1458834203-3392-1-git-send-email-sergey.senozhatsky@gmail.com> <1458834203-3392-2-git-send-email-sergey.senozhatsky@gmail.com> <20160329091439.GC12993@quack.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160329091439.GC12993@quack.suse.cz> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello Jan, On (03/29/16 11:14), Jan Kara wrote: > On Fri 25-03-16 00:43:22, Sergey Senozhatsky wrote: > > @@ -1655,6 +1670,14 @@ asmlinkage int vprintk_emit(int facility, int level, > > raw_spin_lock(&logbuf_lock); > > logbuf_cpu = this_cpu; > > > > + /* > > + * Set printing kthread sleep condition early, under the > > + * logbuf_lock, so it (if RUNNING) will go to console_lock() > > + * and spin on logbuf_lock. > > + */ > > + if (!in_panic && printk_kthread && !need_flush_console) > > + need_flush_console = true; > > + > > if (unlikely(recursion_bug)) { > > static const char recursion_msg[] = > > "BUG: recent printk recursion!"; > > I like the cleaned up need_flush_console handling! Just a suggestion: It > may be more logical to handle need_flush_console setting under logbuf_lock > but after we actually store the message in the buffer, not before. Doesn't > matter for correctness now but may be more future-proof. I wanted to set it asap (when we know for sure that we will log_store()), to have a bit more chances to avoid schedule() in printing thread. well, that's just several log_store()-s, not a big deal, so I guess I can move it to: + if (...) + need_flush_console = true; logbuf_cpu = UINT_MAX; raw_spin_unlock(&logbuf_lock); lockdep_on(); local_irq_restore(flags); -ss