Questions about memory management on Wiz

I'm still trying to understand and tweak some little things on my Wiz and notice a strange behavior that I still cannot fix.

The story:
After closing a specific app (here DrPocketSnes 7.2.1) I can't launch PCSXreARMed r18 in the same session as PCSX just returns to the launcher right after trying to launch it. Rebooting solves it.

My attempts to fix it:
So, I immediately checked what command is used to terminate DrPocketSnes in the gpe file and I found that it seemed ok with:
cd /usr/gp2x/
exec /usr/gp2x/gp2xmenu
To be even more sure, I checked with Termula2X that no Snes process was still in background. No trace of it after using ps or top command (or whatever displays the process table).
So, I decided to clean all caches of Linux using the command 'sync; echo 3 > /proc/sys/vm/drop_caches'. Ok, now all the used RAM is free (I checked again with Termula2X) so no app cache anywhere but still no way to launch PCSX (through the same session again).
I'm out of solution here I have to admit...

What I want to do:
Once I have found a way to fix it, my goal here will be to modify /usr/gp2x/gp2xmenu that will be a simple script including this fix then will redirect to my favorite launcher (GPH one or Win2X) so I am not forced to reboot my device to be able to launch another app. And therefore no need to modify each app gpe script to include the magic command as well (as it will be in the gp2xmenu file itself).

My questions:
As obviously there is STILL something left by DrPocketSnes somewhere (and possibly some other apps), what could it be if it's not in any Linux cache? Or maybe am I missing something to empty (I tried cleaning swap memory but there is none anyway on the Wiz)? Does anyone have deep knowledge about memory management on Linux and could help me on this?

BTW, I can reproduce another strange behavior: after closing PrBoom or eduke32, then launching a cd rom under Temper, framerate and sound become jerky. And of course, only a reboot fixes it.
EDIT: I solved Temper bug. It was because of the use of /proc/cpu/alignment set to 2 in PrBoom and EDuke32, then it made Temper run jerkily, even after emptying all Linux caches (which proves even more than it still remains something somewhere...). So I simply added /proc/cpu/alignment value set to 0 (back to default) in both Doom and Duke gpe script on exit.

Ok I found what caused this. DrPocketSnes had a different warm_2.6.24.ko file from PCSX, which is persistently loaded somewhere in the memory (a place not affected by RAM freeing command), and that made PCSX unable to load. So I used the one of PCSX for DrPocketSnes and it seems to work now for both programs.

EDIT: Apparently, DrPocketSnes does not unload mmuhack on exit as it's not automatic and therefore prevented PCSX from loading his different one.
Source: http://wiki.gp2x.org/articles/u/s/i/Using_the_upper_32MB_of_memory.html:
'Do not forget to unload the module when your program exits, because the other program may want to load a different mmuhack.o and may fail, because you left your mmuhack.o loaded (it does not get unloaded automatically on exit).

// apply mmuhack
mmuhack();

// make sure it is released on exit
atexit(mmuunhack);'

So I found a workaround by using the same mmuhack for DrPocketSnes as PCSX one.

You cannot free memory manually. The kernel does it automatically when a process terminates. Upper memory is not managed by the kernel, but by the drivers and the application itself.

If there is a performance degradation in between apps, then that could mean that an app fiddles with the hardware (mmuhack/warm, pollux_set, "/dev/mem"...), and does not clean up after itself. It can also mean that there is a leaky driver.

Yes, some apps like Temper or DrPocketSnes leave mmuhack stored somewhere, that's why it can make following opened apps have worse performance. If we cannot free this memory, I found a way to prevent this issue from happening by using the same version of mmuhack for all my apps and each of them behave fine so far and with their expected performance.

What do you mean by 'You cannot free memory manually'. Isn't it what 'sync; echo 3 > /proc/sys/vm/drop_caches' do?

To remove mmuhack or warm, use "rmmod". That will free the memory used by the module (very little). Also it will allow the module (or a different version) to be loaded again by the next app. It will not undo any changes to the memory settings that have not already been undone by the first app exiting.

"sync" just flushes buffers (ie makes sure the bits have been moved from memory to the storage device), I dont' think it frees them. Dropping caches might free memory, but that memory would have been given to the app if it had required it, so that should not make the app work better (it may in fact make it load slower).

Yeah I just saw that some app create /dev/mmuhack. Deleting it does not solve any other app launch as, as you said, it won't undo changes done in memory.
Dropping caches does not solve anything as everybody may know, it's only a bad idea under Linux as free memory is considered as useless one. My tests proved that not freeing it makes the app launch faster the 2nd time, which is logical.

Anyway, I could solve all my performance/compatibility issues by tweaking gpe scripts or exchanging mmuhack file between apps. Now I see a little bit clearer about this.

I still have an issue with 2 apps (DrPocketSnes and Temper). Their module (mmuhack and warm) cannot be unloaded with rmmod command: Termula tells me they are still in use whereas they are not and that they have been forcibly loaded. rmmod -f cannot be used as the kernel has not been compiled with this option.

Does someone know how to unload in use modules without rebooting? I looked on some different boards but it seems to be a waste of time. Those 2 in use modules degrade performance of some others, that's quite annoying.

Ah yes. You cannot rmmod warm, because termula "uses" it. It does so because it inherited the file descriptor from gp2xmenu, which in turn inherited it from the app that did not close it properly (this can happen when an app does not use a wrapper script as it's gpe file).

I have attached a little script that tries to close the file descriptors and then unload the modules (rename it to cold.gpe and run it using the launcher).

You wrote 'rmmod warm 2>>cold.log' for mmuhack, I guess you meant 'rmmod mmuhack 2>>cold.log'?

But still needs to be launched twice at least for me. The 1st time, it passes busy module to status '0' (free). Then it closes it. So, maybe it happens only with module in use (with status at least at '1', not '0')?

Attached Files:

When I try with 2 modules loaded (warm and mmuhack set to 1), I still have to launch it at least twice to unload them both.
But anyway, my initial intention was to figure out where this performance drop came from and it's clearer now thanks to your help. Moreover, as that's quite logical to use the same version of each module for all my apps, unloading them is not really needed here. The issue only occured with some different versions of mmuhack/warm between apps. So I updated all my apps with the last one and that's perfect now.