linux-kernel - Re: [RFC 0/2] drivers: spi/i2c: account completions as iowait

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 3 Nov 2014 13:02:22 +0000
From:	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
To:	Wolfram Sang <wsa@...-dreams.de>
Cc:	linux-kernel@...r.kernel.org, linux-i2c@...r.kernel.org,
	linux-spi@...r.kernel.org, Mark Brown <broonie@...nel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...hat.com>,
	Balbir Singh <bsingharora@...il.com>
Subject: Re: [RFC 0/2] drivers: spi/i2c: account completions as iowait

On Sun,  2 Nov 2014 14:58:07 +0100
Wolfram Sang <wsa@...-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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/