linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Joe Perches <joe@perches.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>,
	Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
	Petr Mladek <pmladek@suse.cz>
Subject: Re: linux.git: printk() problem
Date: Sun, 23 Oct 2016 12:32:27 -0700	[thread overview]
Message-ID: <CA+55aFwOBR6z55r2abAT_TuYTHfyuc8f75B2+Z7+Lhr9fzSZRA@mail.gmail.com> (raw)
In-Reply-To: <1477249607.3561.2.camel@perches.com>

On Sun, Oct 23, 2016 at 12:06 PM, Joe Perches <joe@perches.com> wrote:
> On Sun, 2016-10-23 at 11:11 -0700, Linus Torvalds wrote:
>>
>> And those two per se sound fairly easy to handle ("KERN_CONT means
>> append to the line buffer, otherwise flush the line buffer and move to
>> the record buffer").
>>
>> But what complicates things more is then the "console output", which
>> has two issues:
>>
>>  - it is done outside the locking regime for the line buffer and the
>> record buffer.
>>
>>  - it is done on _partial_ line buffers.
>
> EOL KERN_<LEVEL> and thread interleaving still exists.

Note that the thread interleaving is still trivial: it's easily done
at the point where we decide "can we append to the line buffer or
not". That's pretty simple. Just flush the record when the thread
changes.

So the interleaving will never go away, it's very fundamental - unless
we make the line buffer just be a per-thread thing. And yes, that
would be the cleanest solution, but it's also an extra buffer for each
thread, so realistically it's just not going to happen.

End result: I'm not worried about the interleaving. It will cause ugly
output, but we've always had that, and the solution to it is "if you
absolutely don't want interleaving, then don't try to print partial
lines!".

The classic "don't do that then" response, in other world.

No, the real complexity comes from that interaction with the console
output, which is done outside the core log locks, and which currently
has the added thing where we have a "has this line fragment been
flushed or not".

That "has this line fragment been flushed or not" is particularly
painful, because we may have flushed it *partially*. That "cont.cons"
thing is a counter of how many bytes have been flushed, and we can be
in the situation where we have had multiple continuations added to the
line buffer, and only *some* of them have been flushed to the console.

(Reasons for not flushing: we couldn't get the console lock because
another process held it due to logging or whatever).

And then the interface to the actual record logging only has a "all or
nothing was flushed" flag (LOG_NOCONS) to avoid flushing things twice.
So when we actually log the record, we lose the "this line was only
partially printed".

That whole "we've flushed part of the line to the console" thing is
why it would make things so much easier to just log full records to
the console. Getting rid of that gets rid of a lot of ugly and
hard-to-read crap. Yes, the line buffer would still remain, and yes,
you'd still see the interleaving with threads, but that's not
"complexity", that's just "visually ugly output".

                 Linus

  reply	other threads:[~2016-10-23 19:32 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-12 13:30 linux.git: printk() problem Tetsuo Handa
2016-10-12 14:35 ` Michal Hocko
2016-10-12 16:08   ` Joe Perches
2016-10-13  6:26     ` Michal Hocko
2016-10-13  9:29       ` Joe Perches
2016-10-13 10:04         ` Michal Hocko
2016-10-13 10:20           ` Joe Perches
2016-10-13 11:06             ` Michal Hocko
2016-10-12 15:47 ` Linus Torvalds
2016-10-12 16:16   ` Joe Perches
2016-10-12 16:54     ` Linus Torvalds
2016-10-12 18:50       ` [PATCH] acpi_os_vprintf: Use printk_get_level() to avoid unnecessary KERN_CONT Joe Perches
2016-10-13 21:59         ` Rafael J. Wysocki
2016-10-23  9:22   ` linux.git: printk() problem Geert Uytterhoeven
2016-10-23 18:11     ` Linus Torvalds
2016-10-23 19:06       ` Joe Perches
2016-10-23 19:32         ` Linus Torvalds [this message]
2016-10-23 19:46           ` Linus Torvalds
2016-10-24 11:15             ` Geert Uytterhoeven
2016-10-24 14:08             ` Sergey Senozhatsky
2016-10-24 14:23               ` Sergey Senozhatsky
2016-10-24 17:54               ` Linus Torvalds
2016-10-24 17:55                 ` Linus Torvalds
2016-10-25  1:55                   ` Sergey Senozhatsky
2016-10-25  2:06                     ` Linus Torvalds
2016-10-25  2:22                       ` Linus Torvalds
2016-10-25  4:06                         ` Sergey Senozhatsky
2016-10-25  4:13                           ` Joe Perches
2016-10-25  4:15                           ` Linus Torvalds
2016-10-25  4:44                             ` Sergey Senozhatsky
2016-10-25 14:44                         ` Petr Mladek
2016-11-09 15:47                         ` Petr Mladek
2016-10-25  2:24                     ` Sergey Senozhatsky
2016-10-23 20:33           ` Joe Perches
2016-10-23 21:13             ` Linus Torvalds
2016-10-25 14:42       ` Steven Rostedt

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 \
    --in-reply-to=CA+55aFwOBR6z55r2abAT_TuYTHfyuc8f75B2+Z7+Lhr9fzSZRA@mail.gmail.com \
    --to=torvalds@linux-foundation.org \
    --cc=geert@linux-m68k.org \
    --cc=joe@perches.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=penguin-kernel@i-love.sakura.ne.jp \
    --cc=pmladek@suse.cz \
    --cc=sergey.senozhatsky@gmail.com \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).