From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752383AbdLUGwj (ORCPT ); Thu, 21 Dec 2017 01:52:39 -0500 Received: from mail-pl0-f65.google.com ([209.85.160.65]:34182 "EHLO mail-pl0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751378AbdLUGwh (ORCPT ); Thu, 21 Dec 2017 01:52:37 -0500 X-Google-Smtp-Source: ACJfBovysEs9EcAJIj6QdA3v19hZEBTIpIxZmz8ly0pL3Y4qnS03m632gPhuepKMX6MBuz5TOs+FIw== Date: Thu, 21 Dec 2017 15:52:32 +0900 From: Sergey Senozhatsky To: Tetsuo Handa Cc: sergey.senozhatsky.work@gmail.com, mhocko@kernel.org, rostedt@goodmis.org, pmladek@suse.com, tj@kernel.org, sergey.senozhatsky@gmail.com, jack@suse.cz, akpm@linux-foundation.org, peterz@infradead.org, rjw@rjwysocki.net, pavel@ucw.cz, linux-kernel@vger.kernel.org Subject: Re: [RFC][PATCHv6 00/12] printk: introduce printing kernel thread Message-ID: <20171221065232.GB385@jagdpanzerIV> References: <20171219010311.GB8892@jagdpanzerIV> <20171218200806.56a6507e@gandalf.local.home> <20171219012455.GB17164@jagdpanzerIV> <20171219143147.GB15210@dhcp22.suse.cz> <20171220071021.GC21976@jagdpanzerIV> <201712202106.FDB78630.FMFSOtOHJFLQOV@I-love.SAKURA.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201712202106.FDB78630.FMFSOtOHJFLQOV@I-love.SAKURA.ne.jp> User-Agent: Mutt/1.9.2 (2017-12-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Tetsuo, On (12/20/17 21:06), Tetsuo Handa wrote: > Sergey Senozhatsky wrote: > [..] > > Anyway, the rule that "do not try to printk() faster than the kernel can > write to consoles" will remain no matter how printk() changes. and the "faster than the kernel can write to consoles" is tricky. it does not depend ONLY on the performance of underlying console devices. but also on the scheduler and IRQs. simply because of the way we print: void console_unlock(void) { for (;;) { local_irq_save(); text = pick_the_next_pending_logbuf_message(); call_console_drivers(text); local_irq_enable(); ^^^^ preemption + irqs } } on my board call_console_drivers() can spend up to 0.01 of a second printing a _single_ message. which basically means that I'm guaranteed to have preemption in console_unlock() under console_sem after every line it prints [if console_unlock() is invoked from preemptible context]. this, surely, has huge impact on "do not try to printk() faster than this". but there are more points in my "why the patch doesn't work for me" email than just "preemption in console_unlock()". -ss