linux-kernel - Re: [PATCH 5/7] mmc_spi: allow higher timeouts for SPI mode

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]

Message-Id: <200903111714.15911.wolfgang.mues@auerswald.de>
Date:	Wed, 11 Mar 2009 17:14:15 +0100
From:	Wolfgang Mües <wolfgang.mues@...rswald.de>
To:	"Matt Fleming" <matt@...sole-pimps.org>
Cc:	"Pierre Ossman" <drzeus@...eus.cx>,
	"Andrew Morton" <akpm@...ux-foundation.org>,
	"David Brownell" <dbrownell@...rs.sourceforge.net>,
	"Mike Frysinger" <vapier.adi@...il.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 5/7] mmc_spi: allow higher timeouts for SPI mode

Matt,

Am Mittwoch, 11. März 2009 schrieb Matt Fleming:
> OK, but if my machine runs at 100 HZ then a jiffie is 10ms.

Yes.

> Previously (without your patch) we waited for 300ms in the write case 
> and 100ms in the read case.

It depends... There was a change between somewhere between 2.6.26 (300+100ms) 
and 2.6.29 (timeouts calculated from the card parameters).

> So, it's not unreasonable to think that a response is 
> going to take more than 10ms.

Mosts responses (data read and data write with empty buffers in the card) are 
immediately, mostly below 1 ms.

> With your patch we're almost always going 
> to schedule()

No. See above.

> I agree that busy-waiting for 900ms would be a bit mad.

Yes, but this was the previous reality!

> Is there a reason that you didn't implement this with msleep()
> as was noted in the comment above the timeout?

Yes. msleep() is a busy waiting. It is implemented in terms of usleep(), which 
is also busy waiting. The old comment is wrong.

> Do you know approximately how long it
> is before we return from the schedule() under various workloads?

The Linux scheduler tend to prefer processes which call schedule() often, so 
there is a high chance that this process will return from the schedule() at 
the very next tick.

So my timing is:

- busy waiting for 1-2 jiffies
- non-busy-waiting with a delay of 0-1 jiffies afterwards.

I have done some speed measurements for SD card reads and writes, and the 
non-busy waiting has not incured a notable speed decrease.
 
best regards
 
i. A. Wolfgang Mües
-- 
Auerswald GmbH & Co. KG
Hardware Development
Telefon: +49 (0)5306 9219 0
Telefax: +49 (0)5306 9219 94 
E-Mail: Wolfgang.Mues@...rswald.de
Web: http://www.auerswald.de
 
--------------------------------------------------------------
Auerswald GmbH & Co. KG, Vor den Grashöfen 1, 38162 Cremlingen
Registriert beim AG Braunschweig HRA 13289
p.h.G Auerswald Geschäftsführungsges. mbH
Registriert beim AG Braunschweig HRB 7463
Geschäftsführer: Dipl-Ing. Gerhard Auerswald
--
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/