From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758297AbcCVH41 (ORCPT ); Tue, 22 Mar 2016 03:56:27 -0400 Received: from mail-pf0-f196.google.com ([209.85.192.196]:33956 "EHLO mail-pf0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751975AbcCVH4U (ORCPT ); Tue, 22 Mar 2016 03:56:20 -0400 Date: Tue, 22 Mar 2016 16:57:38 +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 v6 0/2] printk: Make printk() completely async Message-ID: <20160322075738.GC1759@swordfish> References: <1458581130-8677-1-git-send-email-sergey.senozhatsky@gmail.com> <20160322064948.GA4459@quack.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160322064948.GA4459@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/22/16 07:49), Jan Kara wrote: > Hi, > > On Tue 22-03-16 02:25:28, Sergey Senozhatsky wrote: > > The patch set is based on slightly updated Jan Kara's patches. > > > > This patch set makes printk() completely asynchronous: new messages > > are getting upended to the kernel printk buffer, but instead of 'direct' > > printing the actual print job is performed by a dedicated kthread. > > This has the advantage that printing always happens from a schedulable > > context and thus we don't lockup any particular CPU or even interrupts. > > > > The patch set is against next-20160321 > > > > the series in total has 3 patches: > > - printk: Make printk() completely async > > - printk: Make wake_up_klogd_work_func() async > > - printk: make console_unlock() async > > > > per discussion, "printk: make console_unlock() async" will be posted > > later on. > > Patches look good to me. I don't think you need to mention the > console_unlock() async patch when it is not part of the series. thanks. > BTW, you seemed to have dropped my patch to skip if there are too > many buffered messages when oops is in progress. Any reason for that? I did. seems that my box has some problems with emails delivery recently: http://marc.info/?l=linux-kernel&m=145821214108806 in short, I'm afraid we can lose valuable data in some cases. for example : hardlockup detector with sysctl_hardlockup_all_cpu_backtrace. : : static void watchdog_overflow_callback(...) : { : ... : if (is_hardlockup()) { : ... : if (sysctl_hardlockup_all_cpu_backtrace && : !test_and_set_bit(0, &hardlockup_allcpu_dumped)) : trigger_allbutself_cpu_backtrace(); : : nmi_panic(regs, msg); : ... : } : ... : } : : trigger_allbutself_cpu_backtrace() can be much more than 100 lines. : trigger_allbutself_cpu_backtrace() may or may not be implemented via : NMI. for example arch/sparc/kernel/process_64.c on a large enough system trigger_allbutself_cpu_backtrace() can easily be more than 100 lines, and trigger_allbutself_cpu_backtrace() may not be able to print the backtraces to console (for example this hardlockuped CPU owns the console_sem) before CPU declares oops_in_progress in nmi_panic()->panic(). -ss