[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170323085143.2cpxgtlmhhrvrcbw@hirez.programming.kicks-ass.net>
Date: Thu, 23 Mar 2017 09:51:43 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
Cc: Steven Rostedt <rostedt@...dmis.org>,
Petr Mladek <pmladek@...e.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
"Rafael J . Wysocki" <rjw@...ysocki.net>,
linux-kernel@...r.kernel.org,
Sergey Senozhatsky <sergey.senozhatsky@...il.com>
Subject: Re: [RFC][PATCH 0/4] printk: introduce printing kernel thread
On Thu, Mar 23, 2017 at 01:09:58PM +0900, Sergey Senozhatsky wrote:
> Hello Peter,
>
> thanks for taking a look.
>
> On (03/22/17 18:59), Peter Zijlstra wrote:
> > On Mon, Mar 06, 2017 at 09:45:50PM +0900, Sergey Senozhatsky wrote:
> > > sysrq is potentially even trickier. can we always wake_up() kernel
> > > thread from sysrq? there probably might be cases when we can't rely
> > > on the scheduler.
> >
> > 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. Also those function names are horrifically
long.
Powered by blists - more mailing lists