GP2X Moving Files To A Ramdisk During Program Execution

[Epicenter]

Since it seems SD card interface's DMA support is broken in the MMSP2 (or the OS in the firmware is perhaps to blame?) reading from the SD card ties up the CPU to nearly 100% capacity, making any program you're running grind to a halt for a moment when you read or write data. This is causing me some issue with OGG Vorbis playback. I'm sure I could copy the active music file to a ram-based filesystem in the Linux OS and play the data from there. But I'm not sure which subdirectory that'd be (/tmp? Would I need to mount my own ramdisk on a mount point?) or what commands from C to use to do it (I imagine they'd be parameters to system().) Anyone tried this?

Alternatively (and more conveniently) would there be a means to malloc() a RAM area, load an OGG file into it and play it with SDL_Mixer still?

Thanks for any tips.

 

[Parkydr]

Use tmpfs e.g.

mkdir temp
mount -t tmpfs temp temp

 

[Squidge]

SD card DMA isn't broken. It just plain doesn't work!

 

[Epicenter]

IIRC MagicEyes said it was supported but they broke it somehow and didn't know why or how to fix it. And apparently didn't care enough to do so.

Use tmpfs e.g.

mkdir temp
mount -t tmpfs temp temp

What system() commands would allow me to mount this FS and move a file there from within my program? Or; I can mount it when the app runs with a script but I still need to be able to copy a file in there, delete it, copy another .. so forth during runtime. Thanks.

 

[Orkie]

I think /tmp is already tmpfs.

If you want to do it through system(), just do this (using a 'temp' directory as the mount point):

system("mount -t tmpfs temp temp");
system("mv -f file temp/file");

 

[Epicenter]

I think /tmp is already tmpfs.

If you want to do it through system(), just do this (using a 'temp' directory as the mount point):

system("mount -t tmpfs temp temp");
system("mv -f file temp/file");

Ah, excellent-- so standard bash syntax is valid in this function then! System() is so poorly documented. I'll give this a crack in a couple hours and see how it goes. Should be a huge improvement to performance if it pans out. Thanks again!

 

[BradN]

I'm not sure if it's really bash syntax, but it should at least be smart enough to search the PATH to find the program. Things like mount and rm are separate programs anyway (although sometimes the shell builds in simple commands like echo just for performance reasons). I bet if you used wildcards or things like that, it wouldn't work though (unlike windows, the shell expands them out on unix before running the program).

Just curious, why don't you load the data into memory instead of putting it in a tmpfs? You don't save any memory, and it seems like it would make programming it more awkward.

 

[Epicenter]

Since this would allow memory management to remain an automatic process-- if I have to start breaking off my own areas with malloc() things are going to get pretty messy, and when I have to start entering exact addresses to use the code gets much, much less multiplatform-friendly. Sure, I can just use Ifdefs, but the less of that I need to do, the better. Also, I don't believe SDL_Mixer is meant to read from a memory area; it's meant to read from a pointer to a file and doing things any other way would make it a pretty awkward and roundabout approach, perhaps more so than using a ramdisk.

 

[Lint]

can't see why you're trying such thing...

in any way you will surely waste some time to completely read the file from SD, in tmpfs case you'll have to wait all the copy proccess (and will take a good time perhaps) instead of option b which is reading on demand from sd

anyway, you can malloc memory, read data into it and you're set (note that's different between malloc'ing and reading data into it and simply mmap'ing the file)
if you're afraid of being swapped out (which also can't see why, as gp2x don't have virtual memory) implemented by somebody else you can also lock the memory, so it will never swap-out

one quite good option that you can have is to build a swapfile into NAND memory (is it faster?) than your program can behave like if there's a 92 +/- megs of ram

also if you want to be polite, you can system() with the SHELL environment variable and use the "-c" option as an argument to shell (wich is probably /bin/bash or /bin/sh anyway) and then you can place any command into next argument like "rm ../*.txt" and let the shell deal with wildcards and stuff like that... note that you must pass only ONE argument after the -c switch

 

[Parkydr]

There's a mount system call.

From man mount(2)

#include <sys/mount.h>

int mount(const char *source, const char *target,
				 const char *filesystemtype, unsigned long mountflags,
				 const void *data);

 

[Epicenter]

I don't mind using the NAND as swap but what if the user has programs there? I'd have to give the option for it to switch back to streaming off the SD card if it can't find the space to do the copy (I would hope the copy command through system() can return an error code so I know it didn't copy correctly...?)

As for malloc()'ing, it'd still take just as long to copy the data into it from SD as it would to copy to a temporary filesystem except just be more complicated? SDL expects a file for the OGG Vorbis source, not a RAM area.

 

[Lint]

Oh, now I see why you want this filesystem approach, so then you can use SDL... I think it's easier and more compatible malloc'ing, but you're likely to have trouble with SDL after...

Anyway, I think that int system() returns -1 if the program can't be executed or 0~127 if the execution succeeds
as you're going sometime to ^C your program during this (long) copy, your program should check if it's children have not got aborted, you can do that with the following code:

  int ret = system("foo");
  if (WIFSIGNALED(ret) && (WTERMSIG(ret) == SIGINT || TERMSIG(ret) == SIGQUIT)) dosomething();

beware that ret can be set to 127 after system() if system can't find a valid shell (like if you set SHELL to a mp3 file) and also that 127 can be returned from some program that got executed

I don't know how fast nand can be, but if it's faster than SD/samba it'll most likely to be turned into swap sooner or later... if user have used all of its nand space (you don't have to occupy the whole 30mb anyway) one can then be punished with slow SD swap/mmaping for simplicity's sake

 

[Gadget]

This is a good post! It's made a difference to my game already. I noticed the slow downs related to ogg playback and just assumed it was related to the read speed of my cheap SD card, but this clears it up. Created a /temp folder and mounted it using tmpfs and now I don't get the issue anymore =D

Thanks all!