public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Karim Yaghmour <karim@opersys.com>
To: Martin Hicks <mort@wildopensource.com>
Cc: Patrick Mochel <mochel@osdl.org>,
	"Randy.Dunlap" <rddunlap@osdl.org>,
	hpa@zytor.com, pavel@ucw.cz, jes@wildopensource.com,
	linux-kernel@vger.kernel.org, wildos@sgi.com,
	Tom Zanussi <zanussi@us.ibm.com>
Subject: Re: [patch] printk subsystems
Date: Tue, 15 Apr 2003 14:40:06 +0000	[thread overview]
Message-ID: <3E9C19C6.70B94C67@opersys.com> (raw)
In-Reply-To: 20030415132741.GR3413@bork.org


Martin Hicks wrote:
> I'm not sure that this addresses the core problem that I'm trying to
> deal with.  The problem is that machines with certain configurations
> (large number of CPUs, Nodes, or a bunch of SCSI and disks) display far
> too many messages to the console, resulting in the log buffer being
> overflowed.  The method that I'm proposing simply allows you to decide
> what gets logged when a printk() happens, depending on the message's
> priority and which subsystem it originated from.

I'm not going to address the "filtering" aspect of the problem, but
I would like to point out that this issue of printk overflowing and
having multiple streams of printk is already solved by relayfs:
http://www.opersys.com/relayfs/

With relayfs, one could easily have multi-channel printks (e.g. one
for each "subsystem" and a main one for important messages of all
subsystems.) The advantages of relayfs are obvious:
- No more lost printks.
- A unified buffering scheme for all subsystems that need to send
data to user-space.
- Lockless per-cpu buffering.
- etc.

We've already started playing around with printk on relayfs, though
we don't have code to offer at this time.

In terms of init-time printk'ing with relayfs, this is the scheme
I suggest:
- Change all statically allocated printk buffers to __initdata.
- Add a registration function in kernel/printk.c which is called
during initialization.
- Said function:
	1) Allocates relayfs channel(s)
	2) Atomically copies existing init-time data to channel
	3) Starts using relayfs channel for all future transfers

That's it. Thereafter, all statically allocated printk buffers are
dropped and all buffer management is left to relayfs.

[The filtering aspect is not taken care of by relayfs because it
is not part of its "mandate". relayfs only aims at providing a
very reliable lightweight high-speed data transfer mechanism for
providing kernel data to user space. Higher-level mechanisms can
easily use different relayfs channels to filter/mux data.]

Karim

===================================================

                 Karim Yaghmour
               karim@opersys.com
      Embedded and Real-Time Linux Expert
===================================================

  reply	other threads:[~2003-04-15 18:32 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-04-07 20:13 [patch] printk subsystems Martin Hicks
2003-04-08 18:41 ` Pavel Machek
2003-04-08 20:02   ` Jes Sorensen
2003-04-08 21:02     ` Pavel Machek
2003-04-08 21:10       ` H. Peter Anvin
2003-04-08 21:57         ` Pavel Machek
2003-04-08 22:02           ` Jes Sorensen
2003-04-08 22:05           ` H. Peter Anvin
2003-04-08 22:55             ` Martin Hicks
2003-04-08 23:10               ` Randy.Dunlap
2003-04-14 18:33                 ` Patrick Mochel
2003-04-14 22:33                   ` Daniel Stekloff
2003-04-16 18:42                     ` Patrick Mochel
2003-04-16 12:35                       ` Daniel Stekloff
2003-04-16 19:16                       ` Martin Hicks
2003-04-16 12:43                         ` Daniel Stekloff
2003-04-17 15:56                           ` Martin Hicks
2003-04-17 13:58                             ` Karim Yaghmour
2003-04-15 13:27                   ` Martin Hicks
2003-04-15 14:40                     ` Karim Yaghmour [this message]
2003-04-08 22:00       ` Jes Sorensen
2003-04-11 19:21 ` Martin Hicks
  -- strict thread matches above, loose matches on Subject: below --
2003-04-08 23:15 Chuck Ebbert
2003-04-17 19:58 Perez-Gonzalez, Inaky
2003-04-17 20:34 ` Karim Yaghmour
2003-04-17 21:03   ` Perez-Gonzalez, Inaky
2003-04-17 21:37     ` Tom Zanussi
2003-04-18  7:21     ` Tom Zanussi
2003-04-18  7:42     ` Greg KH
2003-04-21 15:56     ` Karim Yaghmour
2003-04-21 18:23 Perez-Gonzalez, Inaky
2003-04-21 18:30 ` H. Peter Anvin
2003-04-21 18:42 Perez-Gonzalez, Inaky
2003-04-22  2:49 Perez-Gonzalez, Inaky
2003-04-22  4:34 ` Karim Yaghmour
2003-04-22  3:04 Perez-Gonzalez, Inaky
2003-04-22  6:00 ` Tom Zanussi
2003-04-22  4:02 Perez-Gonzalez, Inaky
2003-04-22  5:52 ` Karim Yaghmour
2003-04-22  6:04 ` Tom Zanussi
2003-04-22  5:09 Perez-Gonzalez, Inaky
2003-04-24 18:22 ` bob
2003-04-22 18:46 Perez-Gonzalez, Inaky
2003-04-22 23:28 ` Karim Yaghmour
2003-04-22 19:02 Perez-Gonzalez, Inaky
2003-04-22 19:03 ` H. Peter Anvin
2003-04-22 21:52 ` Tom Zanussi
2003-04-22 22:53 Perez-Gonzalez, Inaky
2003-04-23  3:58 ` Tom Zanussi
2003-04-23  0:28 Perez-Gonzalez, Inaky
2003-04-24 18:56 Manfred Spraul
2003-04-24 19:10 ` bob

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=3E9C19C6.70B94C67@opersys.com \
    --to=karim@opersys.com \
    --cc=hpa@zytor.com \
    --cc=jes@wildopensource.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mochel@osdl.org \
    --cc=mort@wildopensource.com \
    --cc=pavel@ucw.cz \
    --cc=rddunlap@osdl.org \
    --cc=wildos@sgi.com \
    --cc=zanussi@us.ibm.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