On (09/06/19 16:01), Peter Zijlstra wrote:
> In fact, i've gotten output that is plain impossible with
> the current junk.
Peter, can you post any of those backtraces? Very curious.
-ss
On Fri, Sep 06, 2019 at 04:01:26PM +0200, Peter Zijlstra wrote:
> On Fri, Sep 06, 2019 at 02:42:11PM +0200, Petr Mladek wrote:
> > 7. People would complain when continuous lines become less
> >reliable. It might be most visible when mixing backtraces
> >from all CPUs. Simple sorting by
On 2019-09-06, Peter Zijlstra wrote:
>> I wish it was that simple. It is possible that I see it too
>> complicated. But this comes to my mind:
>>
>> 1. The simple printk_buffer_store(buf, n) is not NMI safe. For this,
>>we might need the reserve-store approach.
>
> Of course it is, and sure
On (09/06/19 16:01), Peter Zijlstra wrote:
> > 2. The simple approach works only with lockless consoles. We need
> >something else for the rest at least for NMI. Simle offloading
> >to a kthread has been blocked for years. People wanted the
> >trylock-and-flush-immediately approach.
>
On Fri, Sep 06, 2019 at 04:01:26PM +0200, Peter Zijlstra wrote:
> On Fri, Sep 06, 2019 at 02:42:11PM +0200, Petr Mladek wrote:
> > 7. People would complain when continuous lines become less
> >reliable. It might be most visible when mixing backtraces
> >from all CPUs. Simple sorting by
On Fri, Sep 06, 2019 at 02:42:11PM +0200, Petr Mladek wrote:
> I wish it was that simple. It is possible that I see it too
> complicated. But this comes to my mind:
>
> 1. The simple printk_buffer_store(buf, n) is not NMI safe. For this,
>we might need the reserve-store approach.
Of course
On (09/06/19 12:49), Peter Zijlstra wrote:
> On Fri, Sep 06, 2019 at 07:09:43PM +0900, Sergey Senozhatsky wrote:
>
> > ---
> > diff --git a/kernel/printk/printk_safe.c b/kernel/printk/printk_safe.c
> > index 139c310049b1..9c73eb6259ce 100644
> > --- a/kernel/printk/printk_safe.c
> > +++
On Fri 2019-09-06 11:06:27, Peter Zijlstra wrote:
> On Thu, Sep 05, 2019 at 04:31:18PM +0200, Peter Zijlstra wrote:
> > So I have something roughly like the below; I'm suggesting you add the
> > line with + on:
> >
> > int early_vprintk(const char *fmt, va_list args)
> > {
> > char
On Fri, Sep 06, 2019 at 07:09:43PM +0900, Sergey Senozhatsky wrote:
> ---
> diff --git a/kernel/printk/printk_safe.c b/kernel/printk/printk_safe.c
> index 139c310049b1..9c73eb6259ce 100644
> --- a/kernel/printk/printk_safe.c
> +++ b/kernel/printk/printk_safe.c
> @@ -103,7 +103,10 @@ static
On (09/06/19 11:06), Peter Zijlstra wrote:
> Another approach is something like:
>
> DEFINE_PER_CPU(int, printk_nest);
> DEFINE_PER_CPU(char, printk_line[4][256]);
>
> int vprintk(const char *fmt, va_list args)
> {
> int c, n, i;
> char *buf;
>
> preempt_disable();
> i =
On Thu 2019-09-05 12:11:01, Steven Rostedt wrote:
>
> [ Added Ted and Linux Plumbers ]
>
> On Thu, 5 Sep 2019 17:38:21 +0200 (CEST)
> Thomas Gleixner wrote:
>
> > On Thu, 5 Sep 2019, Peter Zijlstra wrote:
> > > On Thu, Sep 05, 2019 at 03:05:13PM +0200, Petr Mladek wrote:
> > > > The
On Thu, Sep 05, 2019 at 04:31:18PM +0200, Peter Zijlstra wrote:
> So I have something roughly like the below; I'm suggesting you add the
> line with + on:
>
> int early_vprintk(const char *fmt, va_list args)
> {
> char buf[256]; // teh suck!
> int old, n = vscnprintf(buf,
On 2019-09-05, Steven Rostedt wrote:
>>> But per the above argument of needing the CPU serialization
>>> _anyway_, I don't see a compelling reason not to use it.
>>>
>>> It is simple, it works. Let's use it.
>>>
>>> If you really fancy a multi-writer buffer, you can always switch to
>>> one
[ Added Ted and Linux Plumbers ]
On Thu, 5 Sep 2019 17:38:21 +0200 (CEST)
Thomas Gleixner wrote:
> On Thu, 5 Sep 2019, Peter Zijlstra wrote:
> > On Thu, Sep 05, 2019 at 03:05:13PM +0200, Petr Mladek wrote:
> > > The alternative lockless approach is still more complicated than
> > > the
On Thu, 5 Sep 2019, Peter Zijlstra wrote:
> On Thu, Sep 05, 2019 at 03:05:13PM +0200, Petr Mladek wrote:
> > The alternative lockless approach is still more complicated than
> > the serialized one. But I think that it is manageable thanks to
> > the simplified state tracking. And I might safe use
On Thu, Sep 05, 2019 at 03:05:13PM +0200, Petr Mladek wrote:
> The serialized approach used a lock. It was re-entrant and thus less
> error-prone but still a lock.
>
> The lock was planed to be used not only to access the buffer but also
> for eventual locking inside lockless consoles. It might
On Wed 2019-09-04 14:35:31, Peter Zijlstra wrote:
> On Thu, Aug 08, 2019 at 12:32:25AM +0206, John Ogness wrote:
> > Hello,
> >
> > This is a follow-up RFC on the work to re-implement much of
> > the core of printk. The threads for the previous RFC versions
> > are here: v1[0], v2[1], v3[2].
> >
On Thu, Aug 08, 2019 at 12:32:25AM +0206, John Ogness wrote:
> Hello,
>
> This is a follow-up RFC on the work to re-implement much of
> the core of printk. The threads for the previous RFC versions
> are here: v1[0], v2[1], v3[2].
>
> This series only builds upon v3 (i.e. the first part of this
Hello,
This is a follow-up RFC on the work to re-implement much of
the core of printk. The threads for the previous RFC versions
are here: v1[0], v2[1], v3[2].
This series only builds upon v3 (i.e. the first part of this
series is exactly v3). The main purpose of this series is to
replace the
19 matches
Mail list logo
