From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752139AbdF2HAV (ORCPT ); Thu, 29 Jun 2017 03:00:21 -0400 Received: from rhlx01.hs-esslingen.de ([129.143.116.10]:44888 "EHLO rhlx01.hs-esslingen.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751612AbdF2HAP (ORCPT ); Thu, 29 Jun 2017 03:00:15 -0400 Date: Thu, 29 Jun 2017 09:00:13 +0200 From: Andreas Mohr To: Andreas Mohr Cc: Petr Mladek , Sergey Senozhatsky , Sergey Senozhatsky , Steven Rostedt , Jan Kara , Andrew Morton , Peter Zijlstra , "Rafael J . Wysocki" , Eric Biederman , Greg Kroah-Hartman , Jiri Slaby , Pavel Machek , Tetsuo Handa , linux-kernel@vger.kernel.org Subject: Re: [RFC][PATCHv3 2/5] printk: introduce printing kernel thread Message-ID: <20170629070013.GA14840@rhlx01.hs-esslingen.de> References: <20170509082859.854-1-sergey.senozhatsky@gmail.com> <20170509082859.854-3-sergey.senozhatsky@gmail.com> <20170510055935.GA1966@jagdpanzerIV.localdomain> <20170529092906.GD21894@pathway.suse.cz> <20170531072233.GC7672@jagdpanzerIV.localdomain> <20170628121925.GN1538@pathway.suse.cz> <20170629062620.GA26558@rhlx01.hs-esslingen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170629062620.GA26558@rhlx01.hs-esslingen.de> X-Priority: none User-Agent: Mutt/1.8.0 (2017-02-23) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jun 29, 2017 at 08:26:20AM +0200, Andreas Mohr wrote: > On Wed, Jun 28, 2017 at 02:19:25PM +0200, Petr Mladek wrote: > > On Wed 2017-05-31 16:22:33, Sergey Senozhatsky wrote: > > > so I try to minimize the negative impact of RT prio here. printk_kthread > > > is not special any more. it's an auxiliary kthread that we sometimes > > > wake_up. the thing is that printk_kthread also must offload at some > > > point, basically the same `atomic_print_limit' limit applies to it as > > > well. > > > > You might call cond_resched() outside console_unlock(). But you have > > to keep printk_kthread in runnable state as long as there are pending > > messages. Then scheduler will always prefer this RT task over non-RT > > tasks. Or am I wrong? > > Not sure whether I mentioned this advice before, but: > I believe we should strive to achieve a design where > cond_resched() etc. is *not* needed - > cond_resched() / sleep() etc. likely are signs of extended code smell: > one should strive to achieve handling which has > a properly *precisely*/*strictly* handshaked > request/response (producer/consumer) communication protocol. > I.e., IPC mechanism objects (mutex etc.). > That way, one avoids > the polling-type, imprecise-type "are we there yet? is it our job now?" handling > and instead uses > properly precise (thus, *not* needlessly inefficient!) > scheduler wakeup mechanisms. > > Thus, it's "merely" (hah!) a matter of > designing handling where responsibilities / transitions are clearly spelt out, > thus end up as > properly precisely implemented notifications via IPC mechanisms. Big picture: IMHO (I might be missing something, or even more) this still is a simple producer/consumer type scenario: - you've got any producer inserting payload elements into a *shared* (*global*) store shared store --> store mutex needed - reordering is very undesirable --> keep as one *shared*/*global* data store - producer side(!): in case of hitting a max limit, queuing of elements is discarded completely (emergency situation), BUT with a printk marker element LIMIT EXCEEDED - consumer side: - you've got one central handler which simply knows nothing other (SEPARATION OF CONCERNS!) than how to reliably dequeue and dump (to console) elements, in *any* processing context - producer side (as a special shortcut handling) will *also* subsequently turn to some consumption stuff "dequeue elements until a limit is reached" (here: with its special direct-context limit count) - consumption side is specially constructed to have properly atomic inner handling of decision-making who is the one to dequeue the store at a particular moment in time Thus, you want: - reliable insertion at-any-moment - one consistent/global/shared store - properly precise scheduler decision-making on how the consumer side is done - and of course keep concerns (printk user-side handling, printk payload element store handling, *thread-specific* worker context handling) properly implementation-separate I currently don't see any other complications to this. HTH, Andreas Mohr