From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754692AbcGLQrS (ORCPT ); Tue, 12 Jul 2016 12:47:18 -0400 Received: from mail-pa0-f66.google.com ([209.85.220.66]:36078 "EHLO mail-pa0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751523AbcGLQrR (ORCPT ); Tue, 12 Jul 2016 12:47:17 -0400 Date: Wed, 13 Jul 2016 01:46:50 +0900 From: Sergey Senozhatsky To: Petr Mladek Cc: Viresh Kumar , Sergey Senozhatsky , Andrew Morton , Jan Kara , Tejun Heo , Tetsuo Handa , "linux-kernel@vger.kernel.org" , Byungchul Park , Sergey Senozhatsky Subject: Re: [PATCH v12 0/3] printk: Make printk() completely async Message-ID: <20160712164650.GA451@swordfish> References: <20160513131848.2087-1-sergey.senozhatsky@gmail.com> <20160712155918.GC8597@pathway.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160712155918.GC8597@pathway.suse.cz> User-Agent: Mutt/1.6.2 (2016-07-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On (07/12/16 17:59), Petr Mladek wrote: [..] > > [ 12.874909] sched: RT throttling activated for rt_rq ffffffc0ac13fcd0 (cpu 0) > > [ 12.874909] potential CPU hogs: > > [ 12.874909] printk (292) > > > > On my system, the excessive printing happens during suspend/resume and this > > happened after all the non-boot CPUs were offlined. So, only CPU 0 was left and > > that was doing printing for a long time and so these errors :) > > > > It resulted in missing some print messages eventually as the scheduler probably > > didn't schedule this thread for sometime after that. > > > > Will it be fine to get the priority of this kthread to a somewhat lower value, > > etc ? > > I think that this patch helped only by chance. It causes that any > message without a new line will force printk to the sync mode. > Then it will print even the buffered messages immediately. It > causes printk to behave more or less in the sync mode all the time. KERN_CONT messages are not so often, because they are not SMP-safe, any intruding non-KERN_CONT message will wake_up() printk_kthread. there is a chance, you are right, that printk will operate in sync mode for some time, when we would want it to be async, so 0004 probably better try harder. but KERN_CONT is not what's going on in this case, I think. at lest "[ 12.874909] printk (292)" line suggests so -- printk was in async mode... and somehow non-preemptible for some time... a delay from spin_lock() in call_console_drivers()->write()?... but why would async printk worsen it. > I am still scratching my head about the problem fixed by this patch > and also about suspend problems. yeah, quite puzzled myself. thanks Petr and Viresh for digging this up. I need some sleep now, it's 2 am here, will return back tomorrow. -ss