Be interesting to know where you're lower memory is going. Looking here, the DLLs still use some lower memory, XUL and such grab some private memory in the shared arena for some reason and of course all the supporting DLLs load in low memory and seem to use some for private purposes as well.
Then there are things like FC/2, which when I started it up, used quite a bit of low memory, 30 odd MBs. Looking, it all seemed to be claimed by PMMERGE.
I haven't taken the time to try to figure out where the lower shared memory is going. Upper shared memory is also decreasing, but that isn't as serious, because it ends up around 1 GB left, while lower shared memory goes as low as 48 meg (when it continues to run). It seems that 100 meg of shared memory can disappear very quickly, sometimes. The main user, that I know about, is VBOX 5.0.6, which uses about 100 meg of lower shared memory. Once it gets itself running, it doesn't use any more, and it seems to return all of it when it terminates. The problem is, that other programs may need lower shared memory, while VBOX is running, and that can cause problems. I did try adjusting the VBOX DLLs to load high, but that didn't work, and I haven't tried again (yet).
I also marked some of the supporting DLLs to load high, namely icudt.dll, icuin.dll, icuuc.dll, hunspell10.dll, libvpx4.dll as they used the most and seemed safe. The NSPR and NSS DLLs are probably safe as well. Others, I'm reluctant to mark high as I don't think all programs can use them if marked high. I marked Cairo at one point and got weird results from the screensaver and even mozturbo gave me weird results until I added --Zhigh-mem to the LDFLAGS so have to be careful what is marked high.
Common DLLs, used by many, different, programs are probably not going to work well, if marked high. Anything used by only a single program (or perhaps a suite of related programs) is probably okay, as long as all of the programs can handle it. The main problem is, that there could be one thing, that isn't used much, that will fail. By the time that happens, the user will have forgotten what they did, and the relationship may not be obvious.
Oh well, it is still a step in the right direction, until somebody can figure out how to fix the problem properly.
They all need unlocking before marking as well as mozturbo loads them all and a restart of mozturbo or reboot is required to actually use them.
Have to remember that if any of these DLLs are upgraded, they'll also be locked.
Unloading MozTurbo would seem to be asking for trouble, since the main purpose is to keep the DLLs loaded, to prevent the DLL unload problem. I expect that any future updates would be done with RPM/YUM, and that seems to handle locked files okay. A reboot is probably the best way to handle that, but I am not sure how the user could be told to do a reboot (which is probably a good idea after updating those things anyway).