On Thu, Jun 4, 2009 at 12:38 PM, rketcham <Rich.Ketcham@gmail.com> wrote:

Hi Lewis,

Thanks for your reply - you don't know how frustrated I was with this.

actually, i do :)
when i first encountered this problem (on a different embedded system, not gumstix), i didn't figure this out until after i had gotten to the point of reading the mmc driver source code :)

see below
Verdex right now auto mounts the mmc so I'm not exactly sure where I would
need to edit the mounting command. For the time being I made an init script
that unmounts the card and then remounts it with

mount -t vfat -o async /dev/mmcblk0p1 /mnt/mmc/

# cat S11mount-mmc
#! /bin/sh
# mount-cf Mount the mmc if present

start() {
       echo -n "Unmount MMC ..."
       umount /mnt/mmc
       echo "done."

       echo -n "Mount MMC card ... "
       mount -t vfat -o async /dev/mmcblk0p1 /mnt/mmc/
       echo "done."
stop() {
      echo -n "Unmount MMC Card..."
      umount /mnt/mmc
      echo "done."
restart() {

case "$1" in
       echo $"Usage: $0 {start|stop|restart}"
       exit 1

exit $?

Does this command look correct?  Is there a better place to do this (like
when it's initially mounted)?  The Verdex is more responsive but I still see
that mmcqd still gets up pretty high at times.

i think that looks ok.
i don't know for certain re. the verdex setup but normally you can set these options in fstab.

as for the load of mmcqd, this may or may not be avoidable. 
depending on the requirements and workload of your system there are various things that may impact performance.

the biggest thing impacting performance is rewriting blocks which necessitates filling and erasing pages.  using a different file system such as ext3 that stores filesystem metadata in a journal may help as well.  note that sd cards have built in wear-leveling so there is less need for the file system to be aware of the charateristics of flash.  however, journalling the metadata a la ext3 could yield an improvement if it means fewer rewrites to inodes, etc.

writing multiple files in parallel may be slower than writing whole files if it means that metadata must be updated more frequently. 

avoiding writes using ram disks for temp files is also a great idea.

another thing you need to be aware of is the memory costs of kernel threads like mmcqd.
much of the performance of your system is dependent on your executables and libraries being resident in the buffer cache (i.e not accessed directly off the flash).  if you write a bunch of data, and erases slow down the physical write process, it will not get flushed to disk as fast and will take up more memory.  this may bump other data that you need out of the buffer cache.  this is similar to "swapping" in a desktop machine, only rather than being typically caused by application data being swapped to disk, it is swapping memory mapped executables in from flash.

the effect is similar -- your machine grinds to a halt.

i'm not sure of a good way to diagnose these problems, there is probably a way to find out what's going on, but i don't know offhand of a good solution.  since these are kernel threads, top doesn't have access to the resources used by these threads.  maybe you can use oprofile?  if anyone knows of a good tool for this sort of thing, i'd love to find out about it!

Thanks again!

Lewis Girod wrote:
> Hi Rich,
> The first thing I would try is make sure that your sdcard is mounted with
> the async option.
> 'sync' requires updates for every inode change etc.
> Lewis

View this message in context: http://www.nabble.com/mmcqd-uses-a-large-amount-of-cpu-tp23768078p23873588.html
Sent from the Gumstix mailing list archive at Nabble.com.

OpenSolaris 2009.06 is a cutting edge operating system for enterprises
looking to deploy the next generation of Solaris that includes the latest
innovations from Sun and the OpenSource community. Download a copy and
enjoy capabilities such as Networking, Storage and Virtualization.
Go to: http://p.sf.net/sfu/opensolaris-get
gumstix-users mailing list