All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dmitry Safonov <0x7f454c46@gmail.com>
To: Johan Hovold <johan@kernel.org>
Cc: 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 16:42:45 +0100	[thread overview]
Message-ID: <aa34e2f3-5b19-bf70-8a80-703aca5eeaae@gmail.com> (raw)
In-Reply-To: <20200612152921.GP19480@localhost>

On 6/12/20 4:29 PM, Johan Hovold wrote:
> 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.

I think the number justifies moving them back to header.

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

Fair enough

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

Well, it wasn't related to the debug feature, rather I wanted to cleanup
the header from a bit over-grown functions those have realization
details. And couldn't foresee that a function call would matter for some
setup.

Thanks,
           Dmitry

  reply	other threads:[~2020-06-12 15:42 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
2020-06-12 15:42       ` Dmitry Safonov [this message]
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=aa34e2f3-5b19-bf70-8a80-703aca5eeaae@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.