mmu.library initialization consumes ~1.5MB?!

[AmigaMance]

Hi.
 I don't use the MMULib version of 68040.library or anything else from the archive. I just want to use this command
http://aminet.net/package/util/boot/MuFastChip
to boost Chip-RAM access a little and also the MMU switch of SystemPatch to protect its patches from random memory trashing.
 Both seems to work, but the problem is that just the initialization of the mmu.library eats about 1.5 MB of memory! Is this normal?
 None of these commands is responsible for this. Even loading and locking the library in memory with MuLockLib does this. The library itself is 45.2 KBs long.
 At, least in my case. this is too much memory for just a small benefit and i want to know whether this is normal or not.

 Edit: I wonder if it re-remaps the ROM into Fast-RAM. That would be a waste, since i already soft-kick a ROM image with BlizKick..

[mike-]

I boot to cli with 29664488 total with the mmu.library. (2meg chip 32 fast)
And boot with 29673728 without 9240 should work out to molib and mmu i guess, binary being 864 lib being 44780

[Damion]

What processor libs are you using? IIRC, the latest phase5 libraries had the same function as MuFastChip built in.

[mike-]

68060 v48.15 too?

[Piru]

the problem is that just the initialization of the mmu.library eats about 1.5 MB of memory! Is this normal?

Yes

[AmigaMance]

I boot to cli with 29664488 total with the mmu.library. (2meg chip 32 fast)
And boot with 29673728 without 9240 should work out to molib and mmu i guess, binary being 864 lib being 44780

 Thanks. I tried to load the library with molib and nothing else. Memory consumption is still the same.. :/

[AmigaMance]

What processor libs are you using?

 I have flashed my BPPC with the latest FlashROM.
68040.library 46.13 (Friday  5 October 2001)
© 1999-2000 by Ralph Schmidt

IIRC, the latest phase5 libraries had the same function as MuFastChip built in.

 That's what i thought too! But, is this really true?
Muscan output without running MuFastChip:

MuScan 40.3 (28.11.99) © THOR

68040 MMU detected.
MMU page size is 0x1000 bytes.

Memory map:
0x00000000 - 0x00000FFF CopyBack Remapped to 0x7807B000
0x00001000 - 0x00003FFF CacheInhibit Bundled to 0x78014000
0x00004000 - 0x001FFFFF CacheInhibit NonSerial
0x00200000 - 0x005FFFFF CacheInhibit Bundled to 0x78014000
0x00600000 - 0x00A40FFF CacheInhibit I/O space
0x00A41000 - 0x00A7FFFF CacheInhibit I/O space Bundled to 0x78014000
0x00A80000 - 0x00BBFFFF CacheInhibit Bundled to 0x78014000
0x00BC0000 - 0x00BFFFFF CacheInhibit I/O space
0x00C00000 - 0x00D7FFFF CacheInhibit Bundled to 0x78014000
0x00D80000 - 0x00DFFFFF CacheInhibit I/O space
0x00E00000 - 0x00EFFFFF CacheInhibit Bundled to 0x78014000
0x00F00000 - 0x00F20FFF CacheInhibit I/O space
0x00F21000 - 0x00F7FFFF CacheInhibit
0x00F80000 - 0x00FFFFFF CopyBack
0x01000000 - 0x77FFFFFF CacheInhibit Bundled to 0x78014000
0x78000000 - 0x78013FFF CopyBack
0x78014000 - 0x78015FFF CacheInhibit NonSerial
0x78016000 - 0x7FEFFFFF CopyBack
0x7FF00000 - 0x7FF7FFFF CacheInhibit
0x7FF80000 - 0xDFFFFFFF CacheInhibit Bundled to 0x78014000
0xE0000000 - 0xE101FFFF CacheInhibit I/O space
0xE1020000 - 0xFFEFFFFF CacheInhibit Bundled to 0x78014000
0xFFF00000 - 0xFFF9FFFF CacheInhibit
0xFFFA0000 - 0xFFFAFFFF CacheInhibit I/O space
0xFFFB0000 - 0xFFFBFFFF CacheInhibit
0xFFFC0000 - 0xFFFE0FFF CacheInhibit I/O space
0xFFFE1000 - 0xFFFF7FFF CacheInhibit Bundled to 0x78014000
0xFFFF8000 - 0xFFFFDFFF CopyBack Remapped to 0x78073000
0xFFFFE000 - 0xFFFFFFFF CopyBack Remapped to 0x7FEDC000

And with MuFastChip:

MuScan 40.3 (28.11.99) © THOR

68040 MMU detected.
MMU page size is 0x1000 bytes.

Memory map:
0x00000000 - 0x00000FFF CopyBack Remapped to 0x7807B000
0x00001000 - 0x00003FFF CacheInhibit Bundled to 0x78014000
0x00004000 - 0x001FFFFF CacheInhibit Imprecise NonSerial
0x00200000 - 0x005FFFFF CacheInhibit Bundled to 0x78014000
0x00600000 - 0x00A40FFF CacheInhibit I/O space
0x00A41000 - 0x00A7FFFF CacheInhibit I/O space Bundled to 0x78014000
0x00A80000 - 0x00BBFFFF CacheInhibit Bundled to 0x78014000
0x00BC0000 - 0x00BFFFFF CacheInhibit I/O space
0x00C00000 - 0x00D7FFFF CacheInhibit Bundled to 0x78014000
0x00D80000 - 0x00DFFFFF CacheInhibit I/O space
0x00E00000 - 0x00EFFFFF CacheInhibit Bundled to 0x78014000
0x00F00000 - 0x00F20FFF CacheInhibit I/O space
0x00F21000 - 0x00F7FFFF CacheInhibit
0x00F80000 - 0x00FFFFFF CopyBack
0x01000000 - 0x77FFFFFF CacheInhibit Bundled to 0x78014000
0x78000000 - 0x78013FFF CopyBack
0x78014000 - 0x78015FFF CacheInhibit NonSerial
0x78016000 - 0x7FEFFFFF CopyBack
0x7FF00000 - 0x7FF7FFFF CacheInhibit
0x7FF80000 - 0xDFFFFFFF CacheInhibit Bundled to 0x78014000
0xE0000000 - 0xE101FFFF CacheInhibit I/O space
0xE1020000 - 0xFFEFFFFF CacheInhibit Bundled to 0x78014000
0xFFF00000 - 0xFFF9FFFF CacheInhibit
0xFFFA0000 - 0xFFFAFFFF CacheInhibit I/O space
0xFFFB0000 - 0xFFFBFFFF CacheInhibit
0xFFFC0000 - 0xFFFE0FFF CacheInhibit I/O space
0xFFFE1000 - 0xFFFF7FFF CacheInhibit Bundled to 0x78014000
0xFFFF8000 - 0xFFFFDFFF CopyBack Remapped to 0x78073000
0xFFFFE000 - 0xFFFFFFFF CopyBack Remapped to 0x7FEDC000

 Check out the 3rd line.

Also, busTest
http://aminet.net/package/util/moni/bustest
reports a small increase in Chip-RAM access, but it could be statistical.
And i'd still like to protect the patches of SystemPatch, too.

[AmigaMance]

Yes

 Ok then.
I still wonder why this doesn't happen with mike-'s setup though.

[Karlos]

MMU's perform virtual to physical address mapping. They do this using page tables. Those tables are stored in RAM (where else?).

The more RAM you have in your system, the more pages need to be mapped and so the larger the page table gets.

[AmigaMance]

MMU's perform virtual to physical address mapping. They do this using page tables. Those tables are stored in RAM (where else?).

The more RAM you have in your system, the more pages need to be mapped and so the larger the page table gets.

 Hmm.. I have 128MB of fast ram while mike- has 32MB.
If i have understood you correctly, this explains why MMU occupies so much RAM in my case. :-?
 Thanks!

[Karlos]

Hmm.. I have 128MB of fast ram while mike- has 32MB.
If i have understood you correctly, this explains why MMU occupies so much RAM in my case. :-?
 Thanks!

Sounds about right but I'd need to check the exact sizes. 1.5 MB sounds a bit big still for 128MB. 680x0 MMU pages are usually 4KB each (8K is possible on 040/060 IIRC), so that's 32768 pages at 4K each. Now, there are tiers to MMU page tables too, so you have your table of 4K blocks, then a table of 256K blocks (exact size may be different) and so on. The idea is that they exist in a tree like hierarchy to assist address lookup. Even taking these layers into account, I can't see a page table that size needing 1.5MB. Perhaps your kickstart has also been remapped by mmu.library?

[AmigaMance]

@Karlos

Perhaps your kickstart has also been remapped by mmu.library?

 This is what i was pondering about in the first post:

Edit: I wonder if it re-remaps the ROM into Fast-RAM. That would be a waste, since i already soft-kick a ROM image with BlizKick..

 I'm not running any other MuTools that are indented to do this, like MuMapRom or anything, but i can't tell if this happens or not.
 How can i check this? Does the output of MuScan give you any clue?

[mike-]

@Mance
Could you try replacing mufastchip with molib and see what happens? Im in the midst of an approaching thunderstorm i think.

[AmigaMance]

I have already tried this. See post #6

[Piru]

That's what i thought too! But, is this really true?

It is. I suggested that change actually.

Muscan output without running MuFastChip:

AFAIK muscan outputs the mmu.library MMU table, not the one created by the OS 680x0.library