high CPU load by 'mmcqd' in Ubuntu

[eugenesolo]

how can I solve problem with high CPU load with that thing? looks like mmcqd eats up to 70% of CPU time when write to SD card occured. I did googling, it shows that this may be because sdcard mounted with "sync" flag turned on... but turning this flag off may raise possibility of filesystem corruption

Is it possible to save both preformace _and_ stability of fs on SD?

I guess, i can split my card by two partitions and mount "fast" one without "sync" flag, but I dont want to lose my data in cause of power loss or something.

[eugenesolo]

New tests with SDHC card Class 10 UHS-I, write up to 90MB/s is guaranteed by vendor.

Real test (with 'dd' utility; result from my own application was the same) yielded about 20..22 MB/s write and read. This is just too low for this card. Even if card subsystem can't use UHS mode and thus working in "generic" mode (52 MHz clock on SDIO), its just too slow (4 bit bus x 52 MHz clock => 26 megs per second theoretical maximum; with sequental streaming write overhead is negligible).

Maybe kernel driver cant recognize high-speed cards?

[LeonardoSandova]

The Sabre SD boards do not recognize those type of cards because it does not have the voltage switch circuit (from 3.3 to 1.8 Volts). Regarding the speed you are observing, I think that is normal, because the data pass through the OS so delaying the R/W.

[eugenesolo]

maybe mmcqd itself can be reconfigured/recompiled somehow, with lowe-level fine tuning options? specific kernel parameters? manual hack? something else?

Its just weird that Class 10 cards are so slow. I can believe it. Something is not right here.

[eugenesolo]

I did re-partitioned card, first partition is for rootfs, second for /opt. /opt mounting without sync flag and access time dramatically dropped: from 20+ mins to 1 min 30 sec approximately. Yes, there is no free lunch - database can be easily damaged by sudden power-off, but user will see a really cool performance here (and real filesystem work in background).

But the problem still persists.

Real application still works very slow and sometimes hangs trying to access to 5Megs+ database. When db files is on SATA SSD, it works very fast without hangs. When I'm testing the same software on Cubieboard (small SMC based on Allwinner's SoC A20) running from microSD card, application is slow, but yet faster than on Sabre (10+ mins). CPU load is lower too.

I guess this is a weird problem in mmcqd driver itself. Maybe driver dnot using DMA or interrupts, but only status polling? or pure SPI mode?

[LeonardoSandova]

can you print your /proc/mounts? from where are you copying the file? are you using cp cmd?

[eugenesolo]

I'm not just 'copying', it is working Qt application, accessing to database via sqlite driver. And i'm using 'top' (or 'htop') tool to monitor activity: when database is located on SD card, CPU loading is very high and most consuming process is 'mmcqd', load peaking to ~70%. But when database is on SATA SSD (pretty old 8 Gb card without any label on it), most consuming process is application itself (~10% CPU only).

Same db loads 22 minutes from SD and 1 min 30 sec from SATA SSD. Card is 10 class Transcend SDHC, same thing with 10 class Kingston, on my PC they both pretty fast (I didn't measured the exact speed, but its just comfortable). For me it is clear that performance of SDIO driver is not very optimal. Application and database drivers are not guilty (otherwise CPU load must be high in any case of any storage device).

[LeonardoSandova]

which board are you using? I do not think it is a good idea to place a DB on SD due to its read/write throughput. In case of a sabre sd, you may place it on emmc, for example. Approximately how much data are you reading or writing to the SD? You may get a better picture using strace.

[eugenesolo]

on-board memory for database is not a good idea too, imho - if flash will wear out, it would be very hard to repair. SD card, SATA or maybe USB mass storage - all are replaceable, SD is the cheapest. This is the main reason.

[LeonardoSandova]

I don't get it. emmc is non-volatile but yes, pretty limited in size compare to SD/SATA/USB storage. If you also flash on the the latter, you will also lose data. Depending on your DB size, you may place it on either of the storage devices. if DB wont be so big, the emmc is a good option, in my opinion. You need to configure your system for mirrors, just in case the main DB fails.....

[eugenesolo]

boot device may be fixed, but storage for db and application MUST be removable, it is not my decision :smileyhappy:

[eugenesolo]

board is Sabre Smart Device, with Quad. Yes, i know about "not a good idea", but I'm almost forced to do it - we are looking for appropriate platform for ou new project and i'm testing all available (and relatively cheap) configurations. SD for boot and application is not really neat trick, I admit it, but have a very little choice here...

db size is approximately 5Mb and 50k+ records in it, for testing purposes.

What about gprof?

[LeonardoSandova]

I don't have much experience profiling, but strace is pretty good for a first approach (is the one I commonly used and the good point is that you do not need any recompilation). Also perf and oprofile can give you more insight.