All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Petr Mládek" <pmladek@suse.cz>
To: Konstantin Khlebnikov <koct9i@gmail.com>
Cc: Jiri Kosina <jkosina@suse.cz>,
	Steven Rostedt <rostedt@goodmis.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Ingo Molnar <mingo@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Michal Hocko <mhocko@suse.cz>, Jan Kara <jack@suse.cz>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Dave Anderson <anderson@redhat.com>
Subject: Re: [RFC][PATCH 0/3] x86/nmi: Print all cpu stacks from NMI safely
Date: Wed, 25 Jun 2014 14:21:49 +0200	[thread overview]
Message-ID: <20140625122149.GL8769@pathway.suse.cz> (raw)
In-Reply-To: <CALYGNiM3OH64ULh63cCarTitbjUatZP0mckJ3N9CDusP3mFMRg@mail.gmail.com>

On Tue 2014-06-24 17:32:15, Konstantin Khlebnikov wrote:
> 
> Instead of per-cpu buffers printk might use part of existing ring
> buffer  -- initiator cpu allocates space for
> target cpu and flushes it into common stream after it finish printing.
> Probably this kind of transactional model might be used on single cpu
> for multi-line KERN_CONT.

I wanted to think more about this.

The evident advantage is that we do not need extra buffers. Also it might
be used instead of the cont buffer.

One challenge is that we do not know how much space is needed. If
we do not reserve enough, we might not be able to reserve it later.
This would happen when the main ring buffer is locked by some
blocked process. If we reserve too much, it is a waste of information.
Note that we must remove old messages to make the space.

Also we could not rotate the ring buffer over the reserved space. Then
we might miss the last messages from the normal context when the
system goes down.

Another question is if it could simplify the printk() code. The reservation
logic would be probably more complicated than the current logic around
the cont buffer.

Best Regards,
Petr

      parent reply	other threads:[~2014-06-25 12:21 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-19 21:33 [RFC][PATCH 0/3] x86/nmi: Print all cpu stacks from NMI safely Steven Rostedt
2014-06-19 21:33 ` [RFC][PATCH 1/3] trace_seq: Move the trace_seq code to lib/ Steven Rostedt
2014-06-20  4:45   ` Linus Torvalds
2014-06-20 16:21     ` Steven Rostedt
2014-06-20  5:06   ` Andrew Morton
2014-06-20 16:58     ` Steven Rostedt
2014-06-20 17:12       ` Andrew Morton
2014-06-20 17:17         ` Steven Rostedt
2014-06-20 20:28         ` Steven Rostedt
2014-06-20 20:51           ` Steven Rostedt
2014-06-23 16:33             ` Petr Mládek
2014-06-23 17:03               ` Steven Rostedt
2014-06-22  7:38       ` Johannes Berg
2014-06-23 16:08         ` Steven Rostedt
2014-06-23 17:38           ` Johannes Berg
2014-06-23 18:04             ` Steven Rostedt
2014-06-24  8:19               ` Johannes Berg
2014-06-19 21:33 ` [RFC][PATCH 2/3] printk: Add per_cpu printk func to allow printk to be diverted Steven Rostedt
2014-06-23 16:06   ` Paul E. McKenney
2014-06-19 21:33 ` [RFC][PATCH 3/3] x86/nmi: Perform a safe NMI stack trace on all CPUs Steven Rostedt
2014-06-20 13:58   ` Don Zickus
2014-06-20 14:21     ` Steven Rostedt
2014-06-20 14:55   ` Petr Mládek
2014-06-20 15:17     ` Steven Rostedt
2014-06-23 16:12   ` Paul E. McKenney
2014-06-19 21:56 ` [RFC][PATCH 0/3] x86/nmi: Print all cpu stacks from NMI safely Jiri Kosina
2014-06-19 22:58   ` Steven Rostedt
2014-06-19 23:03     ` Jiri Kosina
2014-06-19 23:19       ` Steven Rostedt
2014-06-19 23:27         ` Jiri Kosina
2014-06-19 23:36           ` Steven Rostedt
2014-06-19 23:38             ` Jiri Kosina
2014-06-20 14:35               ` Petr Mládek
2014-06-24 13:32                 ` Konstantin Khlebnikov
2014-06-25 10:01                   ` Jiri Kosina
2014-06-25 11:04                     ` Konstantin Khlebnikov
2014-06-25 11:57                       ` Petr Mládek
2014-06-25 12:21                   ` Petr Mládek [this message]

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=20140625122149.GL8769@pathway.suse.cz \
    --to=pmladek@suse.cz \
    --cc=akpm@linux-foundation.org \
    --cc=anderson@redhat.com \
    --cc=fweisbec@gmail.com \
    --cc=jack@suse.cz \
    --cc=jkosina@suse.cz \
    --cc=koct9i@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mhocko@suse.cz \
    --cc=mingo@kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=torvalds@linux-foundation.org \
    /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 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.