Bug 2838 - (int-86768) Transfer speeds to MMC/SD cards get very low on N800 with OS2008 when device idles
: Transfer speeds to MMC/SD cards get very low on N800 with OS2008 when device ...
Product: Core
: 4.0
: All Linux
: Low major with 3 votes (vote)
: ---
Assigned To: unassigned
: linux-kernel-bugs
: http://intr.overt.org/blog/?p=66
: performance
  Show dependency tree
Reported: 2008-01-26 05:25 UTC by Philip Langdale
Modified: 2009-01-07 15:11 UTC (History)
7 users (show)

See Also:



You need to log in before you can comment on or make changes to this bug.

Description Philip Langdale (reporter) 2008-01-26 05:25:46 UTC

Try and read from an MMC or SD card

Transfer rates above 4.5MB/s

Transfer rates of about 4.5MB/s



With os2007, I benchmarked a number of cards and was getting transfer rates
exceeding 7MB/s and with my 48MHz patch, I could hit 13MB/s. Now, with OS2008,
all these cards are transfering at about 4.5MB/s.

Amazingly, if load is placed on the CPU, the transfer rate actually increases -
I've seen it go back up over 7MB/s with the right amount of load.

Seems like a problem with the cpu power saving logic. It's not speeding up to
cope with the data transfer.
Comment 1 Philip Langdale (reporter) 2008-01-26 19:04:05 UTC
It seems that the base problem is that the SD bus speed is calculated as a
fraction of the cpu speed and when idle, the cpu speed is 165MHz and the cpu
load of the transfer is not enough of a trigger to kick the speed up.

One way to address it might be to have a cpufreq hook to notice SD transfers
but the ideal fix would be to recalculate the SD bus divider. I have no idea if
the omap2 can do that.
Comment 2 Kimmo Hämäläinen nokia 2008-01-28 08:44:04 UTC
-> kernel
Comment 3 David Hagood 2008-01-30 18:33:38 UTC
*** This bug has been confirmed by popular vote. ***
Comment 4 Andre Klapper maemo.org 2008-07-14 11:05:32 UTC
Blog entry about this is at http://intr.overt.org/blog/?p=70 and custom kernel,
PATCHES and instructions at http://intr.overt.org/4.2008.23-mmc-kernel . Maybe
interesting to get this upstream.

(Philip, for future reference I'd prefer to also see the patches from your blog
linked here to keep this streamlined. ;-)
Comment 5 Philip Langdale (reporter) 2008-07-14 18:00:05 UTC

Nokia people have indicated they won't officially support 48MHz operation
because TI doesn't recommend using it - even though it seems to work for
everyone who's given me feedback.

Also, for the record, the 48MHz patch is a separate matter from the slow
transfers when the CPU is clocked down.
Comment 6 Eero Tamminen nokia 2008-12-18 09:57:49 UTC
Comment from the Nokia BTS:
The clock MMC uses doesn't change when operating point changes -> INVALID.  I
suspect that the ARM side could be clocked lower when the device is otherwise
idle (screen turned off etc) though and that's why transfer slows down.

So, I guess user would need to manually set fixed higher operating point
instead of having it in automatic mode, if one wants higher transfer speeds. 
DVFS code won't be changed in this regards (not lowering ARM side clock while
there's still MMC operation ongoing) for Diablo.
Comment 7 Andre Klapper maemo.org 2009-01-02 14:59:33 UTC
Closing as INVALID for Diablo here too, as per last comment.

No idea about Fremantle plans on DVFS though and whether there will be some
changes or not. :-/
Pinged again in the internal report.
Comment 8 Urho Konttori 2009-01-03 12:31:33 UTC
Ok, I don't want to be splitting hairs, but invalid is not the proper
resolution here. It is obvious that the speed can be increased quite easily.
wontfix would be a more proper resolution - at least that's admitting that
there are things that could be done to improve the situation, but they are too
risky to undertake (for some reason).
Comment 9 Ryan Abel maemo.org 2009-01-03 16:32:42 UTC
(In reply to comment #8)
> (for some reason). 

That 'for some reason' is bricked and non-functional SD cards.
Comment 10 Ryan Abel maemo.org 2009-01-03 16:36:00 UTC
Arguably, this could also be marked FIXED for Fremantle, since the current
kernel code seems to suggest the MMC interface will be 48MHz from the start.
Comment 11 Philip Langdale (reporter) 2009-01-03 22:36:58 UTC
This isn't about the 48MHz MMC bus speed - it's about the fact that on an
otherwise idle system, the CPU will run at a sufficiently low speed that it
becomes the bottleneck, rather than the MMC bus.