All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
	Tejun Heo <tj@kernel.org>,
	Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>,
	linux-kernel@vger.kernel.org, akpm@linux-foundation.org,
	linux-mm@kvack.org, xiyou.wangcong@gmail.com,
	dave.hansen@intel.com, hannes@cmpxchg.org, mgorman@suse.de,
	mhocko@kernel.org, pmladek@suse.com,
	sergey.senozhatsky@gmail.com, vbabka@suse.cz
Subject: Re: [PATCH v3] printk: Add console owner and waiter logic to load balance console writes
Date: Thu, 9 Nov 2017 13:45:48 +0900	[thread overview]
Message-ID: <20171109044548.GC775@jagdpanzerIV> (raw)
In-Reply-To: <20171108222905.426fc73a@vmware.local.home>

On (11/08/17 22:29), Steven Rostedt wrote:
> > On (11/08/17 09:29), Steven Rostedt wrote:
> > > On Wed, 8 Nov 2017 14:19:55 +0900
> > > Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> wrote:
> > >   
> > > > the change goes further. I did express some of my concerns during the KS,
> > > > I'll just bring them to the list.
> > > > 
> > > > 
> > > > we now always shift printing from a save - scheduleable - context to
> > > > a potentially unsafe one - atomic. by example:  
> > > 
> > > And vice versa. We are now likely to go from a unscheduleable context
> > > to a schedule one, where before, that didn't exist.  
> > 
> > the existence of "and vice versa" is kinda alarming, isn't it? it's sort
> > of "yes, we can break some things, but we also can improve some things."
> 
> Not really. Because the heuristic is that what calls printk will do the
> printk.

so what we are looking at

   a) we take over printing. can be from safe context to unsafe context
      [well, bad karma]. can be from unsafe context to a safe one. or from
      safe context to another safe context... or from one unsafe context to
      another unsafe context [bad karma again]. we really never know, no
      one does.

      lots of uncertainties - "may be X, may be Y, may be Z". a bigger
      picture: we still can have the same lockup scenarios as we do
      have today.

      and we also bring busy loop with us, so the new console_sem
      owner [regardless its current context] CPU must wait until the
      current console_sem finishes its call_console_drivers(). I
      mentioned it in my another email, you seemed to jump over that
      part. was it irrelevant or wrong?

vs.

   b) we offload to printk_kthread [safe context].


why (a) is better than (b)?

	-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: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

WARNING: multiple messages have this Message-ID (diff)
From: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
	Tejun Heo <tj@kernel.org>,
	Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>,
	linux-kernel@vger.kernel.org, akpm@linux-foundation.org,
	linux-mm@kvack.org, xiyou.wangcong@gmail.com,
	dave.hansen@intel.com, hannes@cmpxchg.org, mgorman@suse.de,
	mhocko@kernel.org, pmladek@suse.com,
	sergey.senozhatsky@gmail.com, vbabka@suse.cz
Subject: Re: [PATCH v3] printk: Add console owner and waiter logic to load balance console writes
Date: Thu, 9 Nov 2017 13:45:48 +0900	[thread overview]
Message-ID: <20171109044548.GC775@jagdpanzerIV> (raw)
In-Reply-To: <20171108222905.426fc73a@vmware.local.home>

On (11/08/17 22:29), Steven Rostedt wrote:
> > On (11/08/17 09:29), Steven Rostedt wrote:
> > > On Wed, 8 Nov 2017 14:19:55 +0900
> > > Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> wrote:
> > >   
> > > > the change goes further. I did express some of my concerns during the KS,
> > > > I'll just bring them to the list.
> > > > 
> > > > 
> > > > we now always shift printing from a save - scheduleable - context to
> > > > a potentially unsafe one - atomic. by example:  
> > > 
> > > And vice versa. We are now likely to go from a unscheduleable context
> > > to a schedule one, where before, that didn't exist.  
> > 
> > the existence of "and vice versa" is kinda alarming, isn't it? it's sort
> > of "yes, we can break some things, but we also can improve some things."
> 
> Not really. Because the heuristic is that what calls printk will do the
> printk.

so what we are looking at

   a) we take over printing. can be from safe context to unsafe context
      [well, bad karma]. can be from unsafe context to a safe one. or from
      safe context to another safe context... or from one unsafe context to
      another unsafe context [bad karma again]. we really never know, no
      one does.

      lots of uncertainties - "may be X, may be Y, may be Z". a bigger
      picture: we still can have the same lockup scenarios as we do
      have today.

      and we also bring busy loop with us, so the new console_sem
      owner [regardless its current context] CPU must wait until the
      current console_sem finishes its call_console_drivers(). I
      mentioned it in my another email, you seemed to jump over that
      part. was it irrelevant or wrong?

vs.

   b) we offload to printk_kthread [safe context].


why (a) is better than (b)?

	-ss

  reply	other threads:[~2017-11-09  4:45 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-02 17:45 [PATCH v3] printk: Add console owner and waiter logic to load balance console writes Steven Rostedt
2017-11-02 22:16 ` Vlastimil Babka
2017-11-02 22:16   ` Vlastimil Babka
2017-11-03  3:15   ` Steven Rostedt
2017-11-03  3:15     ` Steven Rostedt
2017-11-04  3:13     ` Sergey Senozhatsky
2017-11-04  3:13       ` Sergey Senozhatsky
2017-11-03  4:09   ` John Hubbard
2017-11-03 11:21     ` Steven Rostedt
2017-11-03 11:21       ` Steven Rostedt
2017-11-03 11:54       ` Steven Rostedt
2017-11-03 11:54         ` Steven Rostedt
2017-11-03 11:54         ` Steven Rostedt
2017-11-03 11:54           ` Steven Rostedt
2017-11-03 21:46         ` John Hubbard
2017-11-04  3:34           ` John Hubbard
2017-11-04  8:32             ` [PATCH v3] printk: Add console owner and waiter logic to loadbalance " Tetsuo Handa
2017-11-04  8:32               ` Tetsuo Handa
2017-11-04  8:43               ` Tetsuo Handa
2017-11-04  8:43                 ` Tetsuo Handa
2017-11-06 12:06 ` [PATCH v3] printk: Add console owner and waiter logic to load balance " Tetsuo Handa
2017-11-06 12:06   ` Tetsuo Handa
2017-11-07  1:40   ` Sergey Senozhatsky
2017-11-07  1:40     ` Sergey Senozhatsky
2017-11-07 11:05     ` [PATCH v3] printk: Add console owner and waiter logic to loadbalance " Tetsuo Handa
2017-11-07 11:05       ` Tetsuo Handa
2017-11-08  5:19     ` [PATCH v3] printk: Add console owner and waiter logic to load balance " Sergey Senozhatsky
2017-11-08  5:19       ` Sergey Senozhatsky
2017-11-08 14:29       ` Steven Rostedt
2017-11-08 14:29         ` Steven Rostedt
2017-11-09  0:56         ` Sergey Senozhatsky
2017-11-09  0:56           ` Sergey Senozhatsky
2017-11-09  3:29           ` Steven Rostedt
2017-11-09  3:29             ` Steven Rostedt
2017-11-09  4:45             ` Sergey Senozhatsky [this message]
2017-11-09  4:45               ` Sergey Senozhatsky
2017-11-09  5:06               ` Steven Rostedt
2017-11-09  5:06                 ` Steven Rostedt
2017-11-09  5:33                 ` Sergey Senozhatsky
2017-11-09  5:33                   ` Sergey Senozhatsky

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20171109044548.GC775@jagdpanzerIV \
    --to=sergey.senozhatsky.work@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=dave.hansen@intel.com \
    --cc=hannes@cmpxchg.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@suse.de \
    --cc=mhocko@kernel.org \
    --cc=penguin-kernel@I-love.SAKURA.ne.jp \
    --cc=pmladek@suse.com \
    --cc=rostedt@goodmis.org \
    --cc=sergey.senozhatsky@gmail.com \
    --cc=tj@kernel.org \
    --cc=vbabka@suse.cz \
    --cc=xiyou.wangcong@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.