Original post updated with CDMA Touch Pro XIP for SYS23053, AKU5 (WM6.5) native kernel nk.exe. Tested booting, all works. Includes cachefilt.dll. Answers to questions in above posts:
Quote:
Originally Posted by raidzero
FPOS, do you have any threads on how you do this and the general theory behind it? is cachefilt just a filesystem filter? We have also found out that spinlock patching thr 6.5 NK yields worse performance or did you find a way around that? thanks! I love the work you do with the xip..
|
Somewhere I have a thread on Windows Mobile caching and file system performance. Basically yes cachefult.dll is a filter. What it does is smarter than diskcache.dll which is NOT a filter. Diskcache just reads the next few sectors when a request is made. If the next request happens to be captured by that read then you are golden. It keeps the last X amount of data read in memory (X is defined in boot.rgu - changing it elsewhere doesn't actually change anything - it must be defined in the XIP). Cachefllt is different - it reads the next n sectors that are part of the file, even if they aren't the next n sectors on the storage device. If those sectors are cached by diskcache.dll you are golden. If not, cachefilt.dll reads them (causing diskcache to do its thing again). The memory used for cachefilt.dll comes out of the pagepool. The memory used by diskcache comes out of program memory (you will see filesys.exe memory usage grow and shrink). Now all this said, diskcache.dll speeds up IMGFS reads. Cachefilt.dll does not. Cachefilt.dll ONLY speeds up reads to stuff that's NOT stored in ROM.
I have been running with a spinlocked nk.exe for a while and I can't say I notice an improvement or reduction in performance. I suspect the improvement is in latency, not raw throughput. I also spinlock several HTC OEM drivers and other files in the XIP - basically anything with the old-style ARM instructions.
Quote:
Originally Posted by jucytec
FPOS, how's the 6.5 NK in comparison to 6.1 after your tweak? I too have a Vzw TP and can't run 23053 due to lack of memory.
|
23049 was the last AKU5 build I could run with the 6.1 kernel. 23053 has like 100 more modules and crushed the VM space on the 6.1 kernel. YOu have to move to 6.5. That said, 23053 hauls booty like a pimp driving a girls catholic school bus. So I'd have to say that the combination of 6.5 kernel and 23053 is for SURE the fastest combination I've seen yet, by a substantial margin. Possibly due to the number of modules, possibly due to actual MS improvements, or a combination of both.
Quote:
Originally Posted by indagroove
Um, is there even a kitchen out there that will build properly using xip.bin with a 6.5 NK? Pretty sure you need to use the VK or Platform Rebuilder, which don't use xip.bin.
|
Outside of PlatformRebuilder, there aren't really any XIP kitchens. I do it the old fashioned way. But once an xip.bin is build via any means possible, it is quite possible to have Visual Kitchen use that XIP instead of one created by Platform Rebuilder. If you comment out the XIP sections in the kitchen_build_rom.bat file in Ervius' visual kitchen, it won't touch the XIP. The back-end of visual kitchen is the same as all other kitchens - based on Maimach's IMGFS tools from way back when. The 2nd step is merging the os.nb.payload containing the XIP.bin with the os.nb generated from imgfs2nb and imgfsfromdump.