Re: printk considered harmful (was: [TECH TOPIC] asynchronous printk)

Re: printk considered harmful (was: [TECH TOPIC] asynchronous printk)

[Sergey Senozhatsky]

[Cc linux-kernel]


Hello,

On (11/02/16 10:06), Joe Perches wrote:
> Hello all.
> 
> Can you please post notes for whatever is proposed here somewhere?

we covered 4 topics:

#1 deadlocks and recursion in printk
discussion outcome:
  I published an updated printk_safe patch last week (addresses recursion
  problems in printk). there was no strong opposition, and we agreed
  that per-cpu buffers can help us out.

discussion outcome:
  we agreed that deadlocks in printk must be addressed via printk
  indirection. basically printk() will behave the same way as
  printk_deferred() and, thus, we can, at some point, remove
  printk_deferred().


#2 async printk
discussion outcome:
  we agreed to offload printing duty to a special printk kthread.


#3 pr_cont
discussion outcome:
  out of "problems" list. no work will be done in this area.


#4 console semaphore
discussion outcome:
  we agreed that we can do better here and that it makes sense to do
  what's been proposed in my slides. but, I keep it as a low priority.
  frankly. I'd be happy to see #1-#3 in the mainline in 9-12 months.
  not because it's such an enormesoly hard thing to do, but because we
  probably would want to introduce those changes iteratively, in
  different releases.



p.s.
I uploaded "some sort" of slides to
http://www.slideshare.net/SergeySENOZHATSKY/printk-considered-harmful

	-ss

Re: printk considered harmful (was: [TECH TOPIC] asynchronous printk)

[Sergey Senozhatsky]

fix a typo

On (11/04/16 02:31), Sergey Senozhatsky wrote:
[..]
> #4 console semaphore
> discussion outcome:
>   we agreed that we can do better here and that it makes sense to do
				    ^^^^ IOW, console semaphore thing
				    can be improved

>   what's been proposed in my slides. but, I keep it as a low priority.
>   frankly. I'd be happy to see #1-#3 in the mainline in 9-12 months.
				 ^^^^ #1-#2, of course. but #1 consists
				 of 2 steps.

I'm still not entirely sure if I want to split async pintk and printk
deadlock rework. these things want to come together, for a number of
reasons. or, at least, push the async printk before printk deadlock
rework.

	-ss

Re: printk considered harmful (was: [TECH TOPIC] asynchronous printk)

[Jan Kara]

On Fri 04-11-16 03:01:31, Sergey Senozhatsky wrote:
> fix a typo
> 
> On (11/04/16 02:31), Sergey Senozhatsky wrote:
> [..]
> > #4 console semaphore
> > discussion outcome:
> >   we agreed that we can do better here and that it makes sense to do
> 				    ^^^^ IOW, console semaphore thing
> 				    can be improved
> 
> >   what's been proposed in my slides. but, I keep it as a low priority.
> >   frankly. I'd be happy to see #1-#3 in the mainline in 9-12 months.
> 				 ^^^^ #1-#2, of course. but #1 consists
> 				 of 2 steps.
> 
> I'm still not entirely sure if I want to split async pintk and printk
> deadlock rework. these things want to come together, for a number of
> reasons. or, at least, push the async printk before printk deadlock
> rework.

Yep, please push async printk patches soon. IMHO there's no reason to wait
with that. You can create a git tree with printk patches and push it directly
to Linus since he seems to be fine with the approach...

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

Re: printk considered harmful (was: [TECH TOPIC] asynchronous printk)

[Sergey Senozhatsky]

Hi Jan,

On (11/04/16 00:28), Jan Kara wrote:
[..]
> > I'm still not entirely sure if I want to split async pintk and printk
> > deadlock rework. these things want to come together, for a number of
> > reasons. or, at least, push the async printk before printk deadlock
> > rework.
> 
> Yep, please push async printk patches soon. IMHO there's no reason to wait
> with that. You can create a git tree with printk patches and push it directly
> to Linus since he seems to be fine with the approach...

I'll merge async printk and printk_deferred() patches in one patch set
and then push it (it's just one extra patch in the series; besides we touch
wake_up_klogd_work_func() in async printk anyway), since they really want to
come together. and before async+deferred work I want to push printk_safe. we
already have a somewhat bad experience with printk recursion in async printk,
so I want to stay on the safe side this time.

and, yes, I had this idea of having a printk tree somewhere on github,
so people can start playing with it.

thanks.

	-ss