The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: Doug Anderson <dianders@chromium.org>
Cc: Benson Leung <bleung@chromium.org>,
	Enric Balletbo i Serra <enric.balletbo@collabora.com>,
	"open list:ARM/Rockchip SoC..."
	<linux-rockchip@lists.infradead.org>,
	Nicolas Boichat <drinkcat@chromium.org>,
	Guenter Roeck <groeck@chromium.org>,
	Brian Norris <briannorris@chromium.org>,
	Matthias Kaehlcke <mka@chromium.org>,
	LKML <linux-kernel@vger.kernel.org>,
	linux-spi <linux-spi@vger.kernel.org>
Subject: Re: [PATCH 1/4] spi: For controllers that need realtime always use the pump thread
Date: Tue, 14 May 2019 10:30:38 +0100	[thread overview]
Message-ID: <20190514093038.GB8665@sirena.org.uk> (raw)
In-Reply-To: <CAD=FV=UBic4qywgYQFGEXx_frD9ZoRJX7XGgDbQCvb2CbkBa9w@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1540 bytes --]

On Mon, May 13, 2019 at 01:24:57PM -0700, Doug Anderson wrote:
> On Sun, May 12, 2019 at 10:05 AM Mark Brown <broonie@kernel.org> wrote:

> > If performance is important you probably also want to avoid the context
> > thrashing - executing in the calling context is generally a substantial
> > performance boost.  I can see this causing problems further down the
> > line when someone else turns up with a different requirement, perhaps in
> > an application where the caller does actually have a raised priority
> > themselves and just wanted to make sure that the thread wasn't lower
> > than they are.  I guess it'd be nice if we could check what priority the
> > calling thread has and make a decision based on that but there don't
> > seem to be any facilities for doing that which I can see right now.

> In my case performance is 2nd place to a transfer not getting
> interrupted once started (so we don't break the 8ms rule of the EC).

That's great but other users do care very much about performance and are
also interested in both priority control and avoiding context thrashing.

> My solution in v2 of my series is to take out the forcing in the case
> that the controller wanted "rt" priority and then to add "force" to
> the parameter name.  If someone wants rt priority for the thread but
> doesn't want to force all transfers to the thread we can later add a
> different parameter for that?

I think that's going to be the common case for this.  Forcing context
thrashing is really not something anyone else is asking for.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2019-05-14  9:30 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-10 22:34 [PATCH 0/4] spi: A better solution for cros_ec_spi reliability Douglas Anderson
2019-05-10 22:34 ` [PATCH 1/4] spi: For controllers that need realtime always use the pump thread Douglas Anderson
2019-05-11  0:24   ` Guenter Roeck
2019-05-12  7:33   ` Mark Brown
2019-05-13 20:24     ` Doug Anderson
2019-05-14  9:30       ` Mark Brown [this message]
2019-05-14 14:42         ` Doug Anderson
2019-05-14 15:06           ` Mark Brown
2019-05-10 22:34 ` [PATCH 2/4] spi: Allow SPI devices to specify that they are timing sensitive Douglas Anderson
2019-05-11  0:31   ` Guenter Roeck
2019-05-12  7:42   ` Mark Brown
2019-05-10 22:34 ` [PATCH 3/4] platform/chrome: cros_ec_spi: Set ourselves as " Douglas Anderson
2019-05-11  0:32   ` Guenter Roeck
2019-05-10 22:34 ` [PATCH 4/4] Revert "platform/chrome: cros_ec_spi: Transfer messages at high priority" Douglas Anderson
2019-05-11  0:32   ` Guenter Roeck
2019-05-12  7:45   ` Mark Brown
2019-05-13 15:57     ` Doug Anderson
2019-05-13 16:01       ` Mark Brown
2019-05-13 16:03         ` Doug Anderson
2019-05-13 16:47           ` Mark Brown
2019-05-13 20:21             ` Doug Anderson

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=20190514093038.GB8665@sirena.org.uk \
    --to=broonie@kernel.org \
    --cc=bleung@chromium.org \
    --cc=briannorris@chromium.org \
    --cc=dianders@chromium.org \
    --cc=drinkcat@chromium.org \
    --cc=enric.balletbo@collabora.com \
    --cc=groeck@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=linux-spi@vger.kernel.org \
    --cc=mka@chromium.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