On (01/16/18 10:36), Petr Mladek wrote:
[..]
> > unfortunately disabling preemtion in console_unlock() is a bit
> > dangerous :( we have paths that call console_unlock() exactly
> > to flush everything (not only new pending messages, but everything)
> > that is in logbuf and we cannot return from c
On Tue 2018-01-16 11:23:49, Sergey Senozhatsky wrote:
> On (01/15/18 15:45), Petr Mladek wrote:
> > > I think adding the preempt_disable() would fix printk() but let non
> > > printk console_unlock() still preempt.
> >
> > I would personally remove cond_resched() from console_unlock()
> > complete
On Tue 2018-01-16 13:47:16, Sergey Senozhatsky wrote:
> if you don't mind, let me fix the thing that I broke.
> that would be responsible. I believe I also must say the following:
> Tetsuo, many thanks for reporting the issues for song long, and
> sorry that it took quite a while to revert that
On Tue, 16 Jan 2018 13:47:16 +0900
Sergey Senozhatsky wrote:
> From: Sergey Senozhatsky
> Subject: [PATCH] printk: never set console_may_schedule in console_trylock()
>
> This patch, basically, reverts commit 6b97a20d3a79 ("printk:
> set may_schedule for some of console_trylock() callers").
> T
On Tue, 16 Jan 2018 15:10:13 +0900
Sergey Senozhatsky wrote:
> overall that's very close to what I have in one of my private branches.
> console_trylock_spinning() for some reason does not perform really
> well on my made-up internal printk torture tests. it seems that I
One thing I noticed in m
Hello, Steven.
On Thu, Jan 11, 2018 at 09:55:47PM -0500, Steven Rostedt wrote:
> All I did was start off a work queue on each CPU, and each CPU does one
> printk() followed by a millisecond sleep. No 10,000 printks, nothing
> in an interrupt handler. Preemption is disabled while the printk
> happe
On (01/16/18 10:45), Steven Rostedt wrote:
[..]
> > [1] https://marc.info/?l=linux-mm&m=145692016122716
>
> Especially since Konstantin is working on pulling in all LKML archives,
> the above should be denoted as:
>
> Link:
> http://lkml.kernel.org/r/201603022101.CAH73907.OVOOMFHFFtQJSL%20()%20
On (01/16/18 11:19), Petr Mladek wrote:
[..]
> > [1] https://marc.info/?l=linux-mm&m=145692016122716
> > Fixes: 6b97a20d3a79 ("printk: set may_schedule for some of
> > console_trylock() callers")
> > Signed-off-by: Sergey Senozhatsky
> > Reported-by: Tetsuo Handa
>
> IMHO, this is a step in the
On (01/16/18 11:13), Petr Mladek wrote:
[..]
> IMHO, it would make sense if flushing the printk buffer behaves
> the same when called either from printk() or from any other path.
> I mean that it should be aggressive and allow an effective
> hand off.
>
> It should be safe as long as foo_specific_
On Tue 2018-01-16 11:44:56, Tejun Heo wrote:
> Hello, Steven.
>
> On Thu, Jan 11, 2018 at 09:55:47PM -0500, Steven Rostedt wrote:
> > All I did was start off a work queue on each CPU, and each CPU does one
> > printk() followed by a millisecond sleep. No 10,000 printks, nothing
> > in an interrupt
101 - 110 of 110 matches
Mail list logo
