All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johan Hovold <johan@kernel.org>
To: Dmitry Safonov <0x7f454c46@gmail.com>
Cc: Johan Hovold <johan@kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Jiri Slaby <jslaby@suse.com>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	linux-serial@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 2/3] serial: core: fix sysrq overhead regression
Date: Fri, 12 Jun 2020 17:29:21 +0200	[thread overview]
Message-ID: <20200612152921.GP19480@localhost> (raw)
In-Reply-To: <19008afb-bfbb-35e2-3bd5-e7fd1b7355cc@gmail.com>

On Wed, Jun 10, 2020 at 05:24:57PM +0100, Dmitry Safonov wrote:
> Hi Johan,
> 
> On 6/10/20 4:22 PM, Johan Hovold wrote:
> > Commit 8e20fc391711 ("serial_core: Move sysrq functions from header
> > file") converted the inline sysrq helpers to exported functions which
> > are now called for every received character, interrupt and break signal
> > also on systems without CONFIG_MAGIC_SYSRQ_SERIAL instead of being
> > optimised away by the compiler.
> 
> The part with ifdeffing looks good to me.
> 
> > Inlining these helpers again also avoids the function call overhead when
> > CONFIG_MAGIC_SYSRQ_SERIAL is enabled (e.g. when the port is not used as
> > a console).
> 
> But this one, coul you add measures? (it will also help to understand if
> it's a stable material).

Interrupt processing takes 2-3% longer without the inlining with
8250_omap on a beagleboard for example.

> If one function call actually matters here, than should
> uart_insert_char() also go into header?

Good question, it actually was originally intended to be inlined as all
other per-character processing. Separate discussion though.

The point is that we don't want a rarely used debugging feature to incur
unnecessary additional overhead that can easily be avoided.

Johan

  reply	other threads:[~2020-06-12 15:29 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-10 15:22 [PATCH v2 0/3] serial: core: fix up sysrq regressions Johan Hovold
2020-06-10 15:22 ` [PATCH v2 1/3] Revert "serial: core: Refactor uart_unlock_and_check_sysrq()" Johan Hovold
2020-06-10 15:22 ` [PATCH v2 2/3] serial: core: fix sysrq overhead regression Johan Hovold
2020-06-10 16:24   ` Dmitry Safonov
2020-06-12 15:29     ` Johan Hovold [this message]
2020-06-12 15:42       ` Dmitry Safonov
2020-06-12 15:52   ` Dmitry Safonov
2020-06-10 15:22 ` [PATCH v2 3/3] serial: core: drop redundant sysrq checks Johan Hovold
2020-06-12 15:55   ` Dmitry Safonov
2020-06-10 16:21 ` [PATCH v2 0/3] serial: core: fix up sysrq regressions Andy Shevchenko
2020-06-12 15:31   ` Johan Hovold
2020-06-27 14:16 ` Greg Kroah-Hartman

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=20200612152921.GP19480@localhost \
    --to=johan@kernel.org \
    --cc=0x7f454c46@gmail.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jslaby@suse.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-serial@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 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.