On Mon 2017-04-03 20:53:11, Sergey Senozhatsky wrote:
> On (03/06/17 21:45), Sergey Senozhatsky wrote:
> [..]
> > printk kthread changes the behavior of printk in one _corner case_.
> > The corner case is quite interesting and actually consists of two corner
> > cases. Suppose on SMP system
On Mon 2017-04-03 20:53:11, Sergey Senozhatsky wrote:
> On (03/06/17 21:45), Sergey Senozhatsky wrote:
> [..]
> > printk kthread changes the behavior of printk in one _corner case_.
> > The corner case is quite interesting and actually consists of two corner
> > cases. Suppose on SMP system
On (03/06/17 21:45), Sergey Senozhatsky wrote:
[..]
> printk kthread changes the behavior of printk in one _corner case_.
> The corner case is quite interesting and actually consists of two corner
> cases. Suppose on SMP system there is only one CPU that printk()-s a lot,
> the rest of CPUs
On (03/06/17 21:45), Sergey Senozhatsky wrote:
[..]
> printk kthread changes the behavior of printk in one _corner case_.
> The corner case is quite interesting and actually consists of two corner
> cases. Suppose on SMP system there is only one CPU that printk()-s a lot,
> the rest of CPUs
On (03/24/17 15:43), Petr Mladek wrote:
[..]
> > 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
On (03/24/17 15:43), Petr Mladek wrote:
[..]
> > 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
On Fri 2017-03-24 10:59:36, Sergey Senozhatsky wrote:
> 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?
>
On Fri 2017-03-24 10:59:36, Sergey Senozhatsky wrote:
> 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?
>
On (03/24/17 10:59), Sergey Senozhatsky wrote:
[..]
> 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.
ok, I obviously lied here "this should also return
On (03/24/17 10:59), Sergey Senozhatsky wrote:
[..]
> 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.
ok, I obviously lied here "this should also return
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
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
On Wed 2017-03-22 18:59:20, 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
On Wed 2017-03-22 18:59:20, 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
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
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
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
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 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
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
20 matches
Mail list logo
