From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755531AbeAIWRK (ORCPT + 1 other); Tue, 9 Jan 2018 17:17:10 -0500 Received: from mail-qk0-f193.google.com ([209.85.220.193]:43380 "EHLO mail-qk0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755157AbeAIWRJ (ORCPT ); Tue, 9 Jan 2018 17:17:09 -0500 X-Google-Smtp-Source: ACJfBovGiNf9T8UlUzKhwOZ/vP0sLTy4NwZNb8yHNRUnPIcdj7qiOqnfesYv8QuhikLaIQmea6jLrQ== Date: Tue, 9 Jan 2018 14:17:05 -0800 From: Tejun Heo To: Steven Rostedt Cc: Petr Mladek , Sergey Senozhatsky , Jan Kara , Andrew Morton , Peter Zijlstra , Rafael Wysocki , Pavel Machek , Tetsuo Handa , linux-kernel@vger.kernel.org, Sergey Senozhatsky Subject: Re: [RFC][PATCHv6 00/12] printk: introduce printing kernel thread Message-ID: <20180109221705.GU3668920@devbig577.frc2.facebook.com> References: <20171204134825.7822-1-sergey.senozhatsky@gmail.com> <20171214142709.trgl76hbcdwaczzd@pathway.suse.cz> <20171214152551.GY3919388@devbig577.frc2.facebook.com> <20171214125506.52a7e5fa@gandalf.local.home> <20171214181153.GZ3919388@devbig577.frc2.facebook.com> <20171214132109.32ae6a74@gandalf.local.home> <20171222000932.GG1084507@devbig577.frc2.facebook.com> <20171221231932.27727fab@vmware.local.home> <20180109200620.GQ3668920@devbig577.frc2.facebook.com> <20180109170847.28b41eec@vmware.local.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180109170847.28b41eec@vmware.local.home> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: Hello, Steven. On Tue, Jan 09, 2018 at 05:08:47PM -0500, Steven Rostedt wrote: > The scenario you listed would affect multiple CPUs and multiple CPUs > would be flooding printk. In that case my patch WILL help. Because the > current method, the first CPU to do the printk will get stuck doing the > printk for ALL OTHER CPUs. With my patch, the printk load will migrate > around and there will not be a single CPU that is stuck. Maybe it can break out eventually but that can take a really long time. It's OOM. Most of userland is waiting for reclaim. There isn't all that much going on outside that and there can only be one CPU which is OOMing. The kernel isn't gonna be all that chatty. Thanks. -- tejun