[Windows Mobile] tobbbie:
Thanks, will look that up in the later reference if I find the time. If however the Page-Pool is responsible for paging of modules only, then there should be a correlation of modules (number/total size) and page-pool size. Simple spoken: If I get rid of the big modules (to free VM in my only WM5/6/6.1 slot for this), I can also get down the PP size - in turn freeing some RAM. I really need to play with the tool you recommended some posts down that reveals the page-faults.

The imgfs exclusion from compression can only be set per file, while keeping it marked for compression will have the compress part during build decide which of the 4k blocks will be compressed (hence need CPU to decompress later) and which not to compress (hence directly read). I hope that the imgfs compression will not store in-compressible blocks "compressed" (adding header overhead making them even bigger). As written, the UPX files usually have a large in-compressible part (resulting in uncompressed 4k blocks) and a smaller compressible (resulting in the related 4k blocks to be compressed). Over all I think this is an academic discussion if you can really gain something here. I wonder if there is a practical method to measure such a gain.

I don't care much - just seek for eventual areas where there might still a few bytes of RAM to uncover. Not really needed for the HD2 or other wealthy devices that you and others lurking (and LOL) here in this thread deal with :-)

I have indeed found the list you supplied also for my device it is this:

Template - ROM\ROM.tpl:
MBR start :0x00000000
Sector size :0x0200
Partitions:2
1: XIP 0x00000400-0x0020FFFF CHS-OK
2: IMGFS 0x00210000-0x0021FFFF CHS-OK

FLASH regions:2
0: XIP
1: RDONLY

XIP (Template\<XIP>):
PP(Mb) : 4 (offset: 0x00064558)
KERNEL : WM6.1

dllFirst : 0x01FA01FE (Lo=0x01FA0000; Hi=0x01FE0000)
dllLast : 0x02000000
physFirst : 0x8C080000
physLast : 0x8C27F244
modules : 22
RAMStart : 0x8C280000
RAMFree : 0x8C2F0000
RAMEnd : 0x8FC00000
CopyEntries : 1
CopyOffset : 0x8C0E4FE0
ProfileLength : 0x00000000
ProfileOffset : 0x00000000
files : 7
KernelFlags : 0x00000002
FSRamPercent : 0x00000004
DrivglobStart : 0x00000000
DrivglobLength : 0x00000000
CPUType : 0x01C2 (ARMV4I)
MiscFlags : 0x0002
pExtensions : 0x8C0827FC
TrackingStart : 0x00000000
TrackingLength : 0x00000000

XIP (slots bounds):
SLOT 0 : 0x01FA0000 (dllFirst) -->0x01FE0000 (TrueFFS.dll 0x01FE2000)
SLOT 1 : 0x03E9E000 (TrueFFS.dll)

XIP (cecompr.dll):
XPR: is supported
LZX: is supported
XPH: is not supported

XIP (packages):
044307ec-42a0-4376-d4db-06f549340a39.dsm OEMXIPKERNEL 10.0.15341.0
42d1aab7-6dfa-4c03-9797-d66f7620883d.dsm MSXIPKernelLTK 5.2.18120.400
b5332311-48f1-4b76-ad70-8efa5db8fa3a.dsm MSXIPKernel 5.2.18120.400

boot.rgu - ROM\XIP\OEMXIPKERNEL\boot.rgu

<DONOR> : .\Donor\18120 - not found
<SYS> : SYS\SYS_18120
<ROM\xip.bin> : ROM\xip_18120.bin - not found
<OEM xip.bin> : ROM\xip.bin - not found

So conclusion is that there is nothing to gain - probably I try this KernelFlag = 0x00000000 despite I believe this should not give any gain as the nk.exe is already patched for not checking certificates.

Yes, understood - again I wonder about the true added value here. It is academic gain to understand all this and uncover missed cleanup for released MUI and other resources - but does it speed up an HD2? I mean so much that you notice it when you use it?

Oh well - if I want to follow up with you and the other gurus here I would have to and invest a lot of time and devotion. To be honest I cannot do that. So I am especially thankful that you have spent so much time in explaining things to me here in this thread for the level I need to understand.

My approach is quite simple. I try to understand the strategy, evaluate the options to get a gain for my poor device and then decide where to spend more time/effort. You have helped a lot here to put things in perspective.

Not all things that can be done and understood will really have practical (read noticeable in daily use) benefit despite they may supply a trace of effect in certain tools or logs. For the sake of scientific proof these things are equally important - but not for the poor man's device like mine.

Bottom line for me is:

I will care to investigate more on the page-faults to identify module candidates to put in the list for exceptions to demand paging.

I think it is helpful to have previews of the expected gains in OSB for the cleanups dealing with

resource cleanup (size of code sections to remove)

strip relocations (size of reloc parts to remove) -> as side effect this makes the ROMs impossible to re-locate after a dump, so no option I would ever use.

merge all packages to one -> again effectively blocking the re-use of a build, so nothing I would ever use either.

possibly others I have not dealt with yet.

You really deserve a medal to reply to my questions. After all it is the sharing of knowledge and getting questions answered by an understanding person that promotes your knowledge. This way you educate others to do just the same - which I try to do as well on my level. LMGTFY or RTFM can be helpful sometimes - but I have also seen cases (not here yet) where a bunch of experts just brag about their merits and kick-ass those who are not on their level (and may never want to be). Thanks again!