From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751107AbeAPGKV (ORCPT + 1 other); Tue, 16 Jan 2018 01:10:21 -0500 Received: from mail-pf0-f193.google.com ([209.85.192.193]:38874 "EHLO mail-pf0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750772AbeAPGKT (ORCPT ); Tue, 16 Jan 2018 01:10:19 -0500 X-Google-Smtp-Source: ACJfBovIT+Rp5Ndn/o3i0tlVY2HUJfE2RdDG5dPTY7gNT3Dyw8f0PDEQdOT7MdSeEX7UGM+Gi7sM9w== Date: Tue, 16 Jan 2018 15:10:13 +0900 From: Sergey Senozhatsky To: Petr Mladek Cc: Sergey Senozhatsky , Steven Rostedt , Sergey Senozhatsky , Tejun Heo , akpm@linux-foundation.org, linux-mm@kvack.org, Cong Wang , Dave Hansen , Johannes Weiner , Mel Gorman , Michal Hocko , Vlastimil Babka , Peter Zijlstra , Linus Torvalds , Jan Kara , Mathieu Desnoyers , Tetsuo Handa , rostedt@home.goodmis.org, Byungchul Park , Pavel Machek , linux-kernel@vger.kernel.org Subject: Re: [PATCH v5 0/2] printk: Console owner and waiter logic cleanup Message-ID: <20180116061013.GA19801@jagdpanzerIV> References: <20180111093435.GA24497@linux.suse> <20180111103845.GB477@jagdpanzerIV> <20180111112908.50de440a@vmware.local.home> <20180112025612.GB6419@jagdpanzerIV> <20180111222140.7fd89d52@gandalf.local.home> <20180112100544.GA441@jagdpanzerIV> <20180112072123.33bb567d@gandalf.local.home> <20180113072834.GA1701@tigerII.localdomain> <20180115101743.qh5whicsn6hmac32@pathway.suse.cz> <20180115115013.cyeocszurvguc3xu@pathway.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180115115013.cyeocszurvguc3xu@pathway.suse.cz> 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 Return-Path: Hi, On (01/15/18 12:50), Petr Mladek wrote: > On Mon 2018-01-15 11:17:43, Petr Mladek wrote: > > PS: Sergey, you have many good points. The printk-stuff is very > > complex and we could spend years discussing the perfect solution. > > BTW: One solution that comes to my mind is based on ideas > already mentioned in this thread: > > void console_unlock(void) > { > disable_preemtion(); > > while(pending_message) { > > call_console_drivers(); > > if (too_long_here() && current != printk_kthread) { > wake_up_process(printk_kthread()) > > } > > enable_preemtion(); > } unfortunately disabling preemtion in console_unlock() is a bit dangerous :( we have paths that call console_unlock() exactly to flush everything (not only new pending messages, but everything) that is in logbuf and we cannot return from console_unlock() preliminary in that case. > bool too_long_here(void) > { > return should_resched(); > or > return spent_here() > 1 / HZ / 2; > or > what ever we agree on > } > > > int printk_kthread_func(void *data) > { > while(1) { > if (!pending_messaged) > schedule(); > > if (console_trylock_spinning()) > console_unlock(); > > cond_resched(); > } > } overall that's very close to what I have in one of my private branches. console_trylock_spinning() for some reason does not perform really well on my made-up internal printk torture tests. it seems that I have a much better stability (no lockups and so on) when I also let printk_kthread to sleep on console_sem(). but I will look further. -ss From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg0-f70.google.com (mail-pg0-f70.google.com [74.125.83.70]) by kanga.kvack.org (Postfix) with ESMTP id 3CE4E6B0038 for ; Tue, 16 Jan 2018 01:10:20 -0500 (EST) Received: by mail-pg0-f70.google.com with SMTP id i2so8724385pgq.8 for ; Mon, 15 Jan 2018 22:10:20 -0800 (PST) Received: from mail-sor-f65.google.com (mail-sor-f65.google.com. [209.85.220.65]) by mx.google.com with SMTPS id g184sor285675pgc.162.2018.01.15.22.10.19 for (Google Transport Security); Mon, 15 Jan 2018 22:10:19 -0800 (PST) Date: Tue, 16 Jan 2018 15:10:13 +0900 From: Sergey Senozhatsky Subject: Re: [PATCH v5 0/2] printk: Console owner and waiter logic cleanup Message-ID: <20180116061013.GA19801@jagdpanzerIV> References: <20180111093435.GA24497@linux.suse> <20180111103845.GB477@jagdpanzerIV> <20180111112908.50de440a@vmware.local.home> <20180112025612.GB6419@jagdpanzerIV> <20180111222140.7fd89d52@gandalf.local.home> <20180112100544.GA441@jagdpanzerIV> <20180112072123.33bb567d@gandalf.local.home> <20180113072834.GA1701@tigerII.localdomain> <20180115101743.qh5whicsn6hmac32@pathway.suse.cz> <20180115115013.cyeocszurvguc3xu@pathway.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180115115013.cyeocszurvguc3xu@pathway.suse.cz> Sender: owner-linux-mm@kvack.org List-ID: To: Petr Mladek Cc: Sergey Senozhatsky , Steven Rostedt , Sergey Senozhatsky , Tejun Heo , akpm@linux-foundation.org, linux-mm@kvack.org, Cong Wang , Dave Hansen , Johannes Weiner , Mel Gorman , Michal Hocko , Vlastimil Babka , Peter Zijlstra , Linus Torvalds , Jan Kara , Mathieu Desnoyers , Tetsuo Handa , rostedt@home.goodmis.org, Byungchul Park , Pavel Machek , linux-kernel@vger.kernel.org Hi, On (01/15/18 12:50), Petr Mladek wrote: > On Mon 2018-01-15 11:17:43, Petr Mladek wrote: > > PS: Sergey, you have many good points. The printk-stuff is very > > complex and we could spend years discussing the perfect solution. > > BTW: One solution that comes to my mind is based on ideas > already mentioned in this thread: > > void console_unlock(void) > { > disable_preemtion(); > > while(pending_message) { > > call_console_drivers(); > > if (too_long_here() && current != printk_kthread) { > wake_up_process(printk_kthread()) > > } > > enable_preemtion(); > } unfortunately disabling preemtion in console_unlock() is a bit dangerous :( we have paths that call console_unlock() exactly to flush everything (not only new pending messages, but everything) that is in logbuf and we cannot return from console_unlock() preliminary in that case. > bool too_long_here(void) > { > return should_resched(); > or > return spent_here() > 1 / HZ / 2; > or > what ever we agree on > } > > > int printk_kthread_func(void *data) > { > while(1) { > if (!pending_messaged) > schedule(); > > if (console_trylock_spinning()) > console_unlock(); > > cond_resched(); > } > } overall that's very close to what I have in one of my private branches. console_trylock_spinning() for some reason does not perform really well on my made-up internal printk torture tests. it seems that I have a much better stability (no lockups and so on) when I also let printk_kthread to sleep on console_sem(). but I will look further. -ss -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org