From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966163AbdLSBZC (ORCPT ); Mon, 18 Dec 2017 20:25:02 -0500 Received: from mail-pg0-f43.google.com ([74.125.83.43]:42594 "EHLO mail-pg0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S935034AbdLSBZB (ORCPT ); Mon, 18 Dec 2017 20:25:01 -0500 X-Google-Smtp-Source: ACJfBovyf0WFGigAYY/7WQZkqY//gdjqJ7yY/s1An74eydleCkyZhvBCj9WvdCDzDeN/8K1zJtpjIw== Date: Tue, 19 Dec 2017 10:24:55 +0900 From: Sergey Senozhatsky To: Steven Rostedt Cc: Sergey Senozhatsky , Petr Mladek , Tejun Heo , Sergey Senozhatsky , Jan Kara , Andrew Morton , Peter Zijlstra , Rafael Wysocki , Pavel Machek , Tetsuo Handa , linux-kernel@vger.kernel.org Subject: Re: [RFC][PATCHv6 00/12] printk: introduce printing kernel thread Message-ID: <20171219012455.GB17164@jagdpanzerIV> References: <20171215083151.cu3xbdgmxqkszwso@pathway.suse.cz> <20171215084236.GE468@jagdpanzerIV> <20171215090801.eulx4pg54p667ya5@pathway.suse.cz> <20171218093405.GA31274@jagdpanzerIV> <20171218133101.ri55uwivhc5xwg5y@pathway.suse.cz> <20171218133948.GD31274@jagdpanzerIV> <20171218141353.6shpvcwth34k6dsi@pathway.suse.cz> <20171218124613.1df152da@gandalf.local.home> <20171219010311.GB8892@jagdpanzerIV> <20171218200806.56a6507e@gandalf.local.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171218200806.56a6507e@gandalf.local.home> 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 On (12/18/17 20:08), Steven Rostedt wrote: > > ... do you guys read my emails? which part of the traces I have provided > > suggests that there is any improvement? > > The traces I've seen from you were from non-realistic scenarios. > But I have hit issues with printk()s happening that cause one CPU to do all > the work, where my patch would fix that. Those are the scenarios I'm > talking about. any hints about what makes your scenario more realistic than mine? to begin with, what was the scenario? [..] > But I have hit issues with printk()s happening that cause one CPU to do all > the work, where my patch would fix that. Those are the scenarios I'm > talking about. and this is exactly what I'm still observing. i_do_printks-1992 stops printing, while console_sem is owned by another task. Since log_store() much faster than call_console_drivers() AND console_sem owner is getting preempted for unknown period of time, we end up having pending messages in logbuf... and it's kworker/0:1-135 that prints them all. systemd-udevd-671 [003] d..3 66.334866: offloading: set console_owner kworker/0:1-135 [000] d..2 66.335999: offloading: vprintk_emit()->trylock FAIL will spin? :1 i_do_printks-1992 [002] d..2 66.345474: offloading: vprintk_emit()->trylock FAIL will spin? :0 x 1100 ... systemd-udevd-671 [003] d..3 66.345917: offloading: clear console_owner waiter != NULL :1 -ss