All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dmitry Safonov <0x7f454c46@gmail.com>
To: Johan Hovold <johan@kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: 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: Wed, 10 Jun 2020 17:24:57 +0100	[thread overview]
Message-ID: <19008afb-bfbb-35e2-3bd5-e7fd1b7355cc@gmail.com> (raw)
In-Reply-To: <20200610152232.16925-3-johan@kernel.org>

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).

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

I see quite common pattern in drivers:
: if (!uart_handle_sysrq_char(&up->port, ch))
: 	uart_insert_char(&up->port, byte, 0, ch, TTY_NORMAL);

Don't misunderstand me, but I would prefer keeping headers cleaner
without realization details with the exception if function calls
actually hurts the performance.

Probably, a comment like
/*
 * Keeping these functions in the header improves performance by X% on
 * YYY platform by letting the compiler inline them.
 */
would also help.

Thanks for working on this,
          Dmitry

  reply	other threads:[~2020-06-10 16:25 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 [this message]
2020-06-12 15:29     ` Johan Hovold
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=19008afb-bfbb-35e2-3bd5-e7fd1b7355cc@gmail.com \
    --to=0x7f454c46@gmail.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=johan@kernel.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.