On (03/05/18 22:16), Steven Rostedt wrote:
> > Yes. My point was that "CPU can print one full buffer max" is not
> > guaranteed and not exactly true. There are ways for CPUs to break
> > that O(logbuf) boundary.
>
> Yes, when printk or the consoles have a bug, it can be greater than
> O(logbuf).
On Tue, 6 Mar 2018 11:43:58 +0900
Sergey Senozhatsky wrote:
> One more thing
>
> On (03/06/18 10:52), Sergey Senozhatsky wrote:
> [..]
> > > If you know the baud rate, logbuf size * console throughput is actually
> > > trivial to calculate.
>
> It's trivial when your setup is trivial. In a le
On Tue, 6 Mar 2018 11:53:50 +0900
Sergey Senozhatsky wrote:
> Yes. My point was that "CPU can print one full buffer max" is not
> guaranteed and not exactly true. There are ways for CPUs to break
> that O(logbuf) boundary.
Yes, when printk or the consoles have a bug, it can be greater than
O(lo
On (03/05/18 21:47), Steven Rostedt wrote:
[..]
> At this moment all watchdogs are working fine. And the continuing will
> be done as if it was the first printk. No lockup eminent.
>
[..]
> So basically, the CPU is just printing what that CPU is printing. It
> only becomes an issue if the system
On Tue, 6 Mar 2018 11:00:26 +0900
Sergey Senozhatsky wrote:
> On (03/05/18 15:45), Steven Rostedt wrote:
> > On Mon, 5 Mar 2018 11:14:16 +0900
> > Sergey Senozhatsky wrote:
> >
> > > It can print more than "one full buffer worth". In theory and on
> > > practice.
> >
> > How so? As soon a
One more thing
On (03/06/18 10:52), Sergey Senozhatsky wrote:
[..]
> > If you know the baud rate, logbuf size * console throughput is actually
> > trivial to calculate.
It's trivial when your setup is trivial. In a less trivial case if you
set watchdog threshold based on "logbuf size * console th
On (03/05/18 15:45), Steven Rostedt wrote:
> On Mon, 5 Mar 2018 11:14:16 +0900
> Sergey Senozhatsky wrote:
>
> > It can print more than "one full buffer worth". In theory and on practice.
>
> How so? As soon as another process adds to the buffer, it will take
> over the printing.
The very same
Hello Steven,
Let me Cc Tejun
On (03/05/18 15:58), Steven Rostedt wrote:
> On Mon, 5 Mar 2018 11:14:16 +0900
> Sergey Senozhatsky wrote:
>
> > But I still think that it makes sense to change that "print it all"
> > approach.
> > With more clear/explicit watchdog-dependent limits - we do direct
On Mon, 5 Mar 2018 11:14:16 +0900
Sergey Senozhatsky wrote:
> But I still think that it makes sense to change that "print it all" approach.
> With more clear/explicit watchdog-dependent limits - we do direct printk for
> 1/2 (or 2/3) of a current watchdog threshold value and offload if there is
>
On Mon, 5 Mar 2018 11:14:16 +0900
Sergey Senozhatsky wrote:
> It can print more than "one full buffer worth". In theory and on practice.
How so? As soon as another process adds to the buffer, it will take
over the printing.
-- Steve
On Mon 2018-03-05 14:56:59, Qixuan.Wu wrote:
> Hi Steve,
>
> On Sun, 04 Mar 2018 23:43:23 +0800
> Steven Rostedt wrote:
>
> > Yes, people keep bringing up this scenario.
> > It would require a single burst of printks to all CPUs. And then no
> > more printks after that. The last one will end u
Hi Steve,
On Sun, 04 Mar 2018 23:43:23 +0800
Steven Rostedt wrote:
> Yes, people keep bringing up this scenario.
> It would require a single burst of printks to all CPUs. And then no
> more printks after that. The last one will end up printing the entire
> buffer out the slow console. The thin
On (03/04/18 10:43), Steven Rostedt wrote:
> On Sun, 04 Mar 2018 23:08:23 +0800
> "Qixuan.Wu" wrote:
>
> > Suppose there is one scenario that the system has 100 CPU(0~99). While CPU
> > 0 is
> > calling slow console, CPU 1~99 are calling printk at the same time. And
> > suppose
> > CPU 1 will
On Sun, 04 Mar 2018 23:08:23 +0800
"Qixuan.Wu" wrote:
> Suppose there is one scenario that the system has 100 CPU(0~99). While CPU 0
> is
> calling slow console, CPU 1~99 are calling printk at the same time. And
> suppose
> CPU 1 will be waiter, as per the patch, 2~99 will return directly. Af
Hi Sergey,
Thank you for your fast reply.
On (03/04/18 21:02), Sergey Senozhatsky wrote:
> On (03/04/18 20:10), Qixuan.Wu wrote:
>>Hi Sergey, petr, and Jan,
>> I find you wrote a patch set of "[PATCH v12 0/3] printk: Make printk()
>>completely async"(https://lkml.org/lkml/2016/5/
Cc-ing Steven
On (03/04/18 20:10), Qixuan.Wu wrote:
>Hi Sergey, petr, and Jan,
> I find you wrote a patch set of "[PATCH v12 0/3] printk: Make printk()
>completely async"(https://lkml.org/lkml/2016/5/13/275), and many people
>have reviewd. But I did not see them be taken to upstre
16 matches
Mail list logo
