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: <200903111555.00982.wolfgang.mues@auerswald.de>
Date:	Wed, 11 Mar 2009 15:55:00 +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:
> I am correct in thinking that this patch, in conjuction with your other
> patch, "[PATCH 6/7] mmc_spi: convert timeout handling to jiffies and avoid
> busy waiting", will now penalize my working card and mandate a timeout
> of 1 second?
>
> Without your patch 6 at least mmc_spi_skip() would busy-wait for the
> response, and if my card completed in less than 1 second then it'd just
> return quicker.
>
> It seems you've introduced a performance hit on all MMC over SPI cards.

No.

A timeout is a maximum time to wait, not a minimum time.
Waiting is terminated by a response or by the timeout, whichever comes sooner.

My patch 6 in mmc_spi_skip() is doing a busy-wait for a short while ( less 
than 1 jiffie), and starts to call schedule() inside the loop if the card is 
slower.

My goal was to avoid the long-lasting busy waiting. I have measured times up 
to 900ms! With my patch, the longest busy waiting will be 1 jiffie. 

And yes, if the SD card is sending its response after 5 jiffies, it is 
recognized only after the scheduler schedules this process, which will incure 
a delay to the data transfer. The amount of delay is determined by the number 
of running processes and the number of HZ.

The typical case for this is a series of data block writes to the SD card. 
Until the internal card buffers are full, such writes will be acknowledged by 
a fast response. But if the card buffers are full, you will get one long 
delay until the card controller has written most of the pending data to 
flash.

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/