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

Groups > linux.kernel > #1608070

Re: [RFC][PATCH 0/4] printk: introduce printing kernel thread

Show key headers only | View raw

On (03/23/17 09:51), Peter Zijlstra wrote:
[..]
> > > sysrq runs from interrupt context, right? Should be able to do wakeups.
> > 
> > what I though about was -
> > 	what if there are 'misbehaving' higher prio tasks all the time?
> > 	the existing sysrq would attempt to do printing from irq context
> > 	so it doesn't care about run queues.
> > 
> > does it make sense to you?
> 
> Ah, that's what you meant. Yeah, dunno, I'm still unconvinced about the
> whole printk thread thing.

I see your point.
but I can't think of alternatives that would fix all those lockups and
stalls and at the same time have better guarantees than printk_kthread.


> Also those function names are horrifically long.

right. not happy with the naming either.

so what I'm thinking about right now is:

we have that thing which we call "old printk" mode, which is not
really informative. and my proposal is rename "old" mode and use
"printk rescue" mode instead. because we switch to that mode when
we are trying to "rescue" kernel logs. so the API can be something
like
		printk_rescue_on()
		printk_rescue_off()

opinions?



--- random thoughts ---

another thing that bothers me a bit is that we need to place those
printk_rescue_on/printk_rescue_off switches all over the kernel.
sort of a root cause [in some of the cases] here is the fact that
we don't have any feedback from printk_kthread in vprintk_emit():
	does printk_kthread make any progress?
	do we flush messages to the serial console?
	etc.

and we've got everything we need to have such a feedback in
vprintk_emit():

	a) console is not suspended so console_unlock() can call console drivers
	b) printk_kthread != NULL
	c) we are not in enforced rescue/emergency mode
	d) `log_next_seq' moves forward (always `true', we are in vprintk_emit())
	e) `console_seq' stands still

so we can have an automatic rescue mode fallback in vprintk_emit().
if (a)-(e) are true then we give up on waking up printk_kthread,
switch to rescue mode and attempt to console_trylock() directly from
vprintk_emit(). the part that sucks here is that we need to give
printk_kthread some time to catch up. for instance, if (e) is true
for the past 50 invocations of vprintk_emit(), IOW:

	- we added 50 lines to printk
	- none have been printed on the serial console

then we
	- declare rescue
	- do console_trylock() instead of wake_up() //unless in deferred vprintk_emit()


50 is completely made up. can be 100, or 10, or anything else.


and we can jump between rescue-normal printk modes, so this should
also return back the throttling of tasks which printk() a lot (item
(2) in patch set cover letter) that we used to have.


thoughts?

	-ss

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

Thread

Re: [RFC][PATCH 0/4] printk: introduce printing kernel thread Peter Zijlstra <peterz@infradead.org> - 2017-03-22 19:50 +0100
  Re: [RFC][PATCH 0/4] printk: introduce printing kernel thread Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2017-03-23 05:20 +0100
    Re: [RFC][PATCH 0/4] printk: introduce printing kernel thread Peter Zijlstra <peterz@infradead.org> - 2017-03-23 10:00 +0100
      Re: [RFC][PATCH 0/4] printk: introduce printing kernel thread Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2017-03-24 03:00 +0100
        Re: [RFC][PATCH 0/4] printk: introduce printing kernel thread Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2017-03-24 05:50 +0100
        Re: [RFC][PATCH 0/4] printk: introduce printing kernel thread Petr Mladek <pmladek@suse.com> - 2017-03-24 15:50 +0100
          Re: [RFC][PATCH 0/4] printk: introduce printing kernel thread Sergey Senozhatsky <sergey.senozhatsky@gmail.com> - 2017-03-25 01:30 +0100
  Re: [RFC][PATCH 0/4] printk: introduce printing kernel thread Petr Mladek <pmladek@suse.com> - 2017-03-23 13:10 +0100

csiph-web