From: Petr Mladek <firstname.lastname@example.org> To: Sergey Senozhatsky <email@example.com> Cc: Sergey Senozhatsky <firstname.lastname@example.org>, Tetsuo Handa <email@example.com>, Dmitriy Vyukov <firstname.lastname@example.org>, Steven Rostedt <email@example.com>, Alexander Potapenko <firstname.lastname@example.org>, Fengguang Wu <email@example.com>, Josh Poimboeuf <firstname.lastname@example.org>, LKML <email@example.com>, Linus Torvalds <firstname.lastname@example.org>, Andrew Morton <email@example.com>, firstname.lastname@example.org, Ingo Molnar <email@example.com>, Peter Zijlstra <firstname.lastname@example.org>, Will Deacon <email@example.com> Subject: Re: [PATCH v6 1/3] printk: Add line-buffered printk() API. Date: Thu, 8 Nov 2018 12:24:43 +0100 [thread overview] Message-ID: <firstname.lastname@example.org> (raw) In-Reply-To: <20181108022138.GA2343@jagdpanzerIV> On Thu 2018-11-08 11:21:38, Sergey Senozhatsky wrote: > On (11/07/18 11:21), Petr Mladek wrote: > What is the problem: > - we have tons of CPUs, with tons of tasks running on them, with preemption, > and interrupts, and potentially printk-s coming from various > contexts/CPUs/tasks etc. so one 'cont' buffer is not enough. > > What is the proposed solution: > - if 1 is not enough then 16 will do. And if 16 is not enough then this > is not our problem anymore, it's a kernel misconfiguration and users' > fault. I believe that I mentioned this more times. 16 buffers is the first attempt. We could improve it later in several ways: + add more buffers + combine buffers on stack, dynamically allocated and static ones. BTW: I do not remember seeing mixed lines from anything even close to 16 CPUs. Maybe I was just lucky or my memory is leaky. > Let's have one more look at what we will fix and what we will break. > > 'cont' has premature flushes. > > Why is it good. > It preserves the correct order of events. > > pr_cont("calling foo->init()...."); > foo->init() > printk("Can't allocate buffer\n"); // premature flush > pr_cont("...blah\h"); > > Will end up in the logbuf as: > [12345.123] calling foo->init().... > [12345.124] Can't allocate buffer > [12345.125] ...blah > > Where buffered printk will endup as: > [12345.123] Can't allocate buffer > [12345.124] calling foo->init().......blah We will always have this problem with API using explicit buffers. What do you suggest instead, please? I am afraid that we are running in cycles. The other serious alternative was having per-process and per-context buffers but it was rejected several times. > Not to mention that buffered printk does not flush on panic. > So, frankly, as of now, I don't see buffered printk as a 'cont' > replacement. The static array of buffers can be flushed on panic. > If our problem is OOM and lockdep print outs, then let's address only > those two; let's not "fix" the rest of the kernel, especially the early > boot, - we can break more things than we can mend. Do you have any alternative proposal how to handle OOM and lockdep, please? > [..] > > I opened this problem once and it got lost. So I did not want to > > complicate it at this moment. > > - I don't exactly like the completely of the vprintk_buffered. If > buffered printk is for single line, then it must be for single > line only. My undestanding is that the new API is similar to the current cont buffer from this point of view: + buffer size is LOG_LINE_MAX + it is flushed when full The only difference is that it is flushed also when there is a complete line. Is this a problem, please? > And I'm not buying the "we will need this for printk origin > info injection" argument. I was against this idea several times. The current API does not do anything like this. > - It seems that buffered printk attempts to solve too many problems. > I'd prefer it to address just one. This API tries to handle continuous lines more reliably. Do I miss anything, please? Best Regards, Petr
next prev parent reply other threads:[~2018-11-08 11:24 UTC|newest] Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-11-02 13:31 Tetsuo Handa 2018-11-02 13:31 ` [PATCH 2/3] mm: Use line-buffered printk() for show_free_areas() Tetsuo Handa 2018-11-07 14:07 ` Petr Mladek 2018-11-02 13:31 ` [PATCH 3/3] lockdep: Use line-buffered printk() for lockdep messages Tetsuo Handa 2018-11-02 13:36 ` Peter Zijlstra 2018-11-03 2:00 ` Tetsuo Handa 2018-11-06 8:38 ` Petr Mladek 2018-11-06 9:05 ` Sergey Senozhatsky 2018-11-06 12:57 ` Petr Mladek 2018-11-06 9:56 ` Tetsuo Handa 2018-11-07 15:19 ` Petr Mladek 2018-11-08 4:45 ` Sergey Senozhatsky 2018-11-08 11:37 ` Tetsuo Handa 2018-11-09 6:12 ` Sergey Senozhatsky 2018-11-09 9:55 ` Tetsuo Handa 2018-11-09 15:43 ` Petr Mladek 2018-11-10 2:42 ` Tetsuo Handa 2018-11-23 12:46 ` Petr Mladek 2018-11-23 13:12 ` Tetsuo Handa 2018-11-23 15:56 ` Steven Rostedt 2018-11-24 0:24 ` Tetsuo Handa 2018-11-26 4:34 ` Sergey Senozhatsky 2018-11-28 13:29 ` David Laight 2018-11-29 10:09 ` Tetsuo Handa 2018-11-30 16:01 ` Petr Mladek 2018-11-10 8:52 ` Tetsuo Handa 2018-11-23 12:52 ` Petr Mladek 2018-11-09 14:08 ` Linus Torvalds 2018-11-09 14:42 ` Steven Rostedt 2018-11-08 11:53 ` Petr Mladek 2018-11-08 12:44 ` Sergey Senozhatsky 2018-11-08 14:21 ` Sergey Senozhatsky 2018-11-09 9:54 ` Tetsuo Handa 2018-11-02 14:40 ` [PATCH v6 1/3] printk: Add line-buffered printk() API Matthew Wilcox 2018-11-03 1:55 ` Tetsuo Handa 2018-11-02 18:12 ` kbuild test robot 2018-11-02 18:12 ` kbuild test robot 2018-11-06 14:35 ` Sergey Senozhatsky 2018-11-07 10:21 ` Petr Mladek 2018-11-07 12:54 ` Tetsuo Handa 2018-11-08 2:21 ` Sergey Senozhatsky 2018-11-08 11:24 ` Petr Mladek [this message] 2018-11-08 11:46 ` Tetsuo Handa 2018-11-08 12:30 ` Sergey Senozhatsky 2018-11-09 14:10 ` Petr Mladek 2018-11-12 7:59 ` Sergey Senozhatsky 2018-11-12 10:42 ` Tetsuo Handa 2018-11-17 10:14 ` Tetsuo Handa 2018-11-07 10:52 ` Tetsuo Handa 2018-11-07 11:01 ` David Laight 2018-11-07 12:00 ` Petr Mladek 2018-11-07 11:45 ` Petr Mladek 2018-11-08 2:30 ` Sergey Senozhatsky 2018-11-07 13:41 ` Petr Mladek 2018-11-07 14:06 ` Petr Mladek
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: [PATCH v6 1/3] printk: Add line-buffered printk() API.' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.