public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Josh Triplett <josh@joshtriplett.org>
To: Hannes Reinecke <hare@suse.de>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>,
	Christoph Hellwig <hch@lst.de>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	scsi <linux-scsi@vger.kernel.org>
Subject: Re: scsi: Implement per-cpu logging buffer
Date: Thu, 12 Feb 2015 09:18:26 -0800	[thread overview]
Message-ID: <20150212171826.GA31750@thin> (raw)
In-Reply-To: <54DCAABF.20606@suse.de>

On Thu, Feb 12, 2015 at 02:29:35PM +0100, Hannes Reinecke wrote:
> On 02/12/2015 01:36 PM, Geert Uytterhoeven wrote:
> > On Wed, Feb 11, 2015 at 8:16 PM, Linux Kernel Mailing List
> > <linux-kernel@vger.kernel.org> wrote:
> >> Gitweb:     http://git.kernel.org/linus/;a=commit;h=ded85c193a391a84076d5c6a7a5668fe164a490e
> >> Commit:     ded85c193a391a84076d5c6a7a5668fe164a490e
> >> Parent:     b0a93d96b2814c725161f91a4e35d0c29ec0f95b
> >> Refname:    refs/heads/master
> >> Author:     Hannes Reinecke <hare@suse.de>
> >> AuthorDate: Thu Jan 8 07:43:42 2015 +0100
> >> Committer:  Christoph Hellwig <hch@lst.de>
> >> CommitDate: Fri Jan 9 15:44:28 2015 +0100
> >>
> >>     scsi: Implement per-cpu logging buffer
> >>
> >>     Implement a per-cpu buffer for formatting messages to avoid line breaks
> >>     up under high load.  This patch implements scmd_printk() and
> >>     sdev_prefix_printk() using the per-cpu buffer and makes sdev_printk() a
> >>     wrapper for sdev_prefix_printk().
> >>
> >>     Tested-by: Robert Elliott <elliott@hp.com>
> >>     Reviewed-by: Robert Elliott <elliott@hp.com>
> >>     Signed-off-by: Hannes Reinecke <hare@suse.de>
> >>     Signed-off-by: Christoph Hellwig <hch@lst.de>
> > 
> >> --- /dev/null
> >> +++ b/drivers/scsi/scsi_logging.c
> > 
> >> +#define SCSI_LOG_SPOOLSIZE 4096
> >> +#define SCSI_LOG_BUFSIZE 128
> >> +
> >> +#if (SCSI_LOG_SPOOLSIZE / SCSI_LOG_BUFSIZE) > BITS_PER_LONG
> >> +#warning SCSI logging bitmask too large
> >> +#endif
> >> +
> >> +struct scsi_log_buf {
> >> +       char buffer[SCSI_LOG_SPOOLSIZE];
> >> +       unsigned long map;
> >> +};
> >> +
> >> +static DEFINE_PER_CPU(struct scsi_log_buf, scsi_format_log);
> > 
> > Do we really need a static 4 KiB per-CPU buffer?
> > 
> > bloat-o-meter:
> > 
> > add/remove: 183/94 grow/shrink: 314/211 up/down: 33467/-21291 (12176)
> > function                                     old     new   delta
> > scsi_format_log                                -    4100   +4100
> > handle_mm_fault                             1794    2750    +956
> > scsi_log_print_sense_hdr                       -     774    +774
> > proc_keys_show                                 -     770    +770
> > 
> Define 'need'.
> We don't absolutely 'need' it. (Configure it out and it's gone).
> 
> But when we want to avoid several logging messages coming in from
> various CPUs overwriting each other and _not_ introduce additional
> latency by locking a single buffer, then yes.
> 
> We can possibly reduce it to, say, 1KiB or even lower by imposing
> stricter rules on the logging functions.
> But I don't see a way around the per-CPU buffer.

It seems very odd to introduce a mechanism like this specifically for
SCSI, rather than introducing a generic per-CPU buffered-print mechanism
in printk, controlled by a config option.  That option could then
automatically go away when !SMP, or !PRINTK, or if users don't actually
care about message ordering.

Also, this doesn't seem to be configurable at all.

- Josh Triplett

  reply	other threads:[~2015-02-12 17:18 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20150211191614.349AF660DDA@gitolite.kernel.org>
2015-02-12 12:36 ` scsi: Implement per-cpu logging buffer Geert Uytterhoeven
2015-02-12 13:29   ` Hannes Reinecke
2015-02-12 17:18     ` Josh Triplett [this message]
2015-02-13  8:48       ` Hannes Reinecke
2015-02-13 15:45         ` Josh Triplett
2015-02-14 14:29           ` Hannes Reinecke
2015-02-14 16:13             ` Geert Uytterhoeven
2015-02-14 17:11             ` James Bottomley
2015-02-16  2:36             ` Josh Triplett
2015-02-17 13:01         ` Jiri Kosina

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=20150212171826.GA31750@thin \
    --to=josh@joshtriplett.org \
    --cc=geert@linux-m68k.org \
    --cc=hare@suse.de \
    --cc=hch@lst.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox