linux-spi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
To: Wolfram Sang <wsa@the-dreams.de>
Cc: linux-kernel@vger.kernel.org, linux-i2c@vger.kernel.org,
	linux-spi@vger.kernel.org, Mark Brown <broonie@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	Balbir Singh <bsingharora@gmail.com>
Subject: Re: [RFC 0/2] drivers: spi/i2c: account completions as iowait
Date: Mon, 3 Nov 2014 13:02:22 +0000	[thread overview]
Message-ID: <20141103130222.1c53fa39@alan.etchedpixels.co.uk> (raw)
In-Reply-To: <1414936689-2707-1-git-send-email-wsa@the-dreams.de>

On Sun,  2 Nov 2014 14:58:07 +0100
Wolfram Sang <wsa@the-dreams.de> wrote:

> So, I recently learned that there is wait_for_completion_io_* because one I2C
> driver uses it instead of wait_for_completion_*. I want consistency, so
> technically the io-versions seem to be the correct ones to me, because, well,
> we are waiting for IO.
> 
> However, researching the net, users currently interpret iowait entirely as
> blkio wait. Furthermore, io_schedule() calls delayacct_blkio_{start|end}() which
> worked fine for my tests with I2C but might show that iowait was really meant as
> blkiowait? So, should other subsystems use it?

I don't think so. The traditional Unix use of I/O wait is block I/O wait,
in order to account for paging/swapping in "uptime".

The other problem is that if you change the way it behaves you'll get
lots of hate mail from people running server farms as all their load
balancing and cluster management changes behaviour, plus baffled users
wondering why their system is now busy and it wasn't in the last release.

I'm not really sure how it should be accounted - arguably an SPI
transaction to an SD card is I/O wait but one to a display controller on
the same i2c bus is not.

The other question you have to solve is that people are adding i2c and
SPI slave support both in Android space and now perhaps upstream. How do
you I/O account those transactions ?

Alan

  parent reply	other threads:[~2014-11-03 13:02 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-02 13:58 [RFC 0/2] drivers: spi/i2c: account completions as iowait Wolfram Sang
2014-11-02 13:58 ` [RFC 1/2] i2c: " Wolfram Sang
     [not found] ` <1414936689-2707-1-git-send-email-wsa-z923LK4zBo2bacvFa/9K2g@public.gmane.org>
2014-11-02 13:58   ` [RFC 2/2] spi: " Wolfram Sang
2014-11-02 16:59   ` [RFC 0/2] drivers: spi/i2c: " Peter Zijlstra
     [not found]     ` <20141102165943.GT10501-IIpfhp3q70z/8w/KjCw3T+5/BudmfyzbbVWyRVo5IupeoWH0uzbU5w@public.gmane.org>
2014-11-03 19:31       ` Wolfram Sang
2014-11-03 13:02 ` One Thousand Gnomes [this message]
     [not found]   ` <20141103130222.1c53fa39-mUKnrFFms3BCCTY1wZZT65JpZx93mCW/@public.gmane.org>
2014-11-03 19:45     ` Wolfram Sang

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=20141103130222.1c53fa39@alan.etchedpixels.co.uk \
    --to=gnomes@lxorguk.ukuu.org.uk \
    --cc=broonie@kernel.org \
    --cc=bsingharora@gmail.com \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-spi@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=wsa@the-dreams.de \
    /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;
as well as URLs for NNTP newsgroup(s).