Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1677451

Re: [RFC][PATCHv3 2/5] printk: introduce printing kernel thread

Show all headers | View raw

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

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Re: [RFC][PATCHv3 2/5] printk: introduce printing kernel thread Petr Mladek <pmladek@suse.com> - 2017-06-28 14:20 +0200
  Re: [RFC][PATCHv3 2/5] printk: introduce printing kernel thread Andreas Mohr <andi@lisas.de> - 2017-06-29 08:30 +0200
    Re: [RFC][PATCHv3 2/5] printk: introduce printing kernel thread Andreas Mohr <andi@lisas.de> - 2017-06-29 09:10 +0200
  Re: [RFC][PATCHv3 2/5] printk: introduce printing kernel thread Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2017-06-29 09:40 +0200
    Re: [RFC][PATCHv3 2/5] printk: introduce printing kernel thread Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> - 2017-06-29 13:40 +0200
    Re: [RFC][PATCHv3 2/5] printk: introduce printing kernel thread Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2017-06-30 09:10 +0200
      Re: [RFC][PATCHv3 2/5] printk: introduce printing kernel thread Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> - 2017-06-30 12:30 +0200
        Re: [RFC][PATCHv3 2/5] printk: introduce printing kernel thread Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2017-06-30 14:00 +0200
          Re: [RFC][PATCHv3 2/5] printk: introduce printing kernel thread Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> - 2017-06-30 14:50 +0200
            Re: [RFC][PATCHv3 2/5] printk: introduce printing kernel thread Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2017-06-30 15:00 +0200
      Re: [RFC][PATCHv3 2/5] printk: introduce printing kernel thread Petr Mladek <pmladek@suse.com> - 2017-06-30 15:20 +0200
        Re: [RFC][PATCHv3 2/5] printk: introduce printing kernel thread Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2017-06-30 15:40 +0200
          Re: [RFC][PATCHv3 2/5] printk: introduce printing kernel thread Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2017-07-03 13:20 +0200
        Re: [RFC][PATCHv3 2/5] printk: introduce printing kernel thread Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2017-06-30 16:20 +0200
    Re: [RFC][PATCHv3 2/5] printk: introduce printing kernel thread Petr Mladek <pmladek@suse.com> - 2017-06-30 14:00 +0200
      Re: [RFC][PATCHv3 2/5] printk: introduce printing kernel thread Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2017-06-30 14:50 +0200
        Re: [RFC][PATCHv3 2/5] printk: introduce printing kernel thread Steven Rostedt <rostedt@goodmis.org> - 2017-06-30 15:40 +0200
          Re: [RFC][PATCHv3 2/5] printk: introduce printing kernel thread Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2017-06-30 16:30 +0200
            Re: [RFC][PATCHv3 2/5] printk: introduce printing kernel thread Steven Rostedt <rostedt@goodmis.org> - 2017-06-30 16:50 +0200
              Re: [RFC][PATCHv3 2/5] printk: introduce printing kernel thread Sergey Senozhatsky <sergey.senozhatsky@gmail.com> - 2017-07-01 04:00 +0200

csiph-web