08 April 2024, 16:49 | #21 |
Registered User
Join Date: Mar 2013
Location: Lahti / Finland
Age: 53
Posts: 454
|
How to move AmigaOS 3.1 "expansion.library" into fast memory without MMU?
|
08 April 2024, 17:21 | #22 |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,327
|
|
08 April 2024, 17:23 | #23 | |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,327
|
Quote:
Why? The expansion.library is only used to identify and configure the hardware, and not any time further. To answer your question, you cannot. The purpose of the library is to find autoconfiguring RAM, and for that reason, it cannot be in the RAM it is supposed to configure. Exec is (re-)constructed after expansion has run, and thus, if autoconfig RAM is present, is moved to fast RAM. |
|
08 April 2024, 17:29 | #24 |
Registered User
Join Date: Mar 2013
Location: Lahti / Finland
Age: 53
Posts: 454
|
|
08 April 2024, 17:51 | #25 | |
Registered User
Join Date: Oct 2017
Location: Amsterdam
Posts: 231
|
Quote:
Unfortunately the specific modules that are provided with the BlizKick package stopped working with 3.1.4+ roms. P.S. because the "LoadModule method" only needs one reboot and there is more freedom to exchange various "modules", I prefer the LoadModule method. This comes with the extra benefit of being able to also use MuProtectModules for instance. When using LoadModule the startup of my system looks like this (roughly): 1. MuMove4K NOREBOOT 2. LoadModule L:System-Startup NOMEMFKICK REVERSE ROMUPDATE 3. MuFastZero ON FASTEXEC MOVESSP 4. MuFastRom ON PROTECT 5. MuProtectModules ON REMAP When using BlizKick it looks like: 1. BlizKick ROM 2. MuMove4K 3. MuFastZero ON FASTEXEC MOVESSP |
|
08 April 2024, 18:38 | #26 |
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,359
|
To free a small chunk of precious chipmem ?
Then why does it stay in the system after that ? I've seen open count of 4 under WB. |
08 April 2024, 18:41 | #27 |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,327
|
About 1K? Serious?
Because "after that" is "after all hardware expansions have been configured", and depending on your hardware, this can be rather late. BindDrivers is one program that is relatively late, RTG hardware is also pretty late when the RTG stack is loaded. |
08 April 2024, 18:51 | #28 |
Registered User
Join Date: Jan 2008
Location: Warsaw/Poland
Age: 56
Posts: 2,050
|
Dependent where this chunk is allocated in chip mem.
It can waste only 1 KB of chip memory, but in wrong place it can waste much more chip memory f.e 5KB. Freeing later this if is unnecessary is good idea. Or simple make mirror (copy) in fast memory, and free later. |
08 April 2024, 19:26 | #29 |
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,359
|
Yes, serious. Remember that the waste of one individual, though not much, is added to everyone else's waste. Little things add together. There are no small savings.
This doesn't explain why the library stays open after everything has been configured. |
08 April 2024, 19:49 | #30 | |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,327
|
Quote:
It doesn't stay open, or at least not unless every user closes it correctly after having opened it. It stays in memory, and the reason is quite simple: Because it is unclear at which time everything is configured. Despite, it doesn't cost a lot of memory in first place. |
|
08 April 2024, 20:40 | #31 | ||
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,359
|
Quote:
Quote:
Else it would be fine, it is open first time in chipmem, then closed, then flushed if necessary, then eventually reopened and able to go in previously configured fastmem. Remember that even though 1k isn't much, it can still turn an allocation that works into an allocation that fails. Sometimes every kilobyte counts, especially for chipmem. |
||
08 April 2024, 23:08 | #32 | ||
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,327
|
It is pointless to discuss with ignorant people lacking the background. Here is the background for educating you.
A library is "open" if its open count is non-zero. Otherwise, it is not open. That is something *different* from "resident in RAM". A library that is resident in RAM and closed can *decide* by itself to be no longer resident in RAM by unloading itself when flushed. Once it is needed again, it is loaded or recreated by ramlib. However, ROM based libraries usually do not implement this function, though in principle some could. dos, exec, graphics and many many other cannot be flushed simply because it is assumed that everybody will need them all the time anyhow. That intuition can be flushed is relatively recent and was added in v47 to be able to update it even if already loaded, and it is a very rare exception of a ROM-based system library implementing this feature. The expansion library neither can be flushed since it *also* carries the database of the system expansions it identified, and these system expansions cannot be re-detected once the system is running, thus its data base and library base need to remain in RAM until the system is shut down or rebooted. Quote:
Quote:
The database can neither be relocated since there is no "obtain and release" interface to it. You only get the ConfigDev corresponding to a hardware, and then hold on it. A program has no means to "release" an already obtained configuration, thus it cannot be removed under the feed of a program either. I remember that <1K is really not much memory indeed. it's making a rumble for nothing probably for the purpose of making a rumble and nothing else, especially without knowing the details and the background. |
||
08 April 2024, 23:14 | #33 | ||
Registered User
Join Date: Apr 2013
Location: Norway
Posts: 258
|
Quote:
Thanks for this reply @Amiga68k ! I've been doing experiments with combinations of using Blizkick and LoadModule to get the performance back, and it seems like the puzzle is solved now thanks to all you guys. I tried both the Blizkick and LoadModule-approach, and it seems like the LoadModule-approach is the one that seems to give me most performance and the cleanest installation of AmigaOS3.2 I tried with and without MMULib, MuMove4k, MuFastZero and so on, and the setup that revived the old speed (and even surpass 3.1 speeds in some cases) was the LoadModule-approach from the post above. It will only need one reboot which also was one of my goals. Intuition feels snappy again and disk loads are as fast as I can remember them. The only thing I'm wondering now is how the procedure is to migrate the system from a ROM-based installation to a disk-based installation. How does the installer detect this, and is it possible to run the installer again when the system is loaded with LoadModule? Is it then aware that the system is diskbased, or will it still detect the system as a ROMbased-system like it will when ROM is kicked using Blizkick? And one last question: Why is MuMove4k not a part of the MMULib disk for AmigaOS3.2? It's present in the Aminet archive. Quote:
Last edited by Firestone; 08 April 2024 at 23:20. |
||
08 April 2024, 23:29 | #34 |
Registered User
Join Date: Jan 2008
Location: Warsaw/Poland
Age: 56
Posts: 2,050
|
Sorry, but which problem is updating expansion.library for extra/missing calls for new kick 3.3?
If something can be made better than for old kickstarts then can be done. Same for support for files over 2GB. And over 2GB RAM limit. Only good idea is necessary. |
08 April 2024, 23:36 | #35 | |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,327
|
Quote:
Because the goal of an operating system distribution is a little bit different. The purpose of the distribution is to make it easily accessible to the user, and have a running and stable system once it is installed. This goal was obtained. Optimizing and tweaking the system is up to the user if it is even necessary. The system runs and it stable with the default startup-sequence. Every tweaking beyond this point is a bit hardware specific and not so easy. |
|
08 April 2024, 23:47 | #36 | ||
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,327
|
Quote:
"It's as in real life: Once you make a mistake, you have to support it for your lifetime." If expansion is ever supposed to be updated, then rather into the direction of detecting autoconfiguring hardware on other bus systems and provide them to the user, but transparently with existing interfaces. That is a potential and useful development direction, and not to worry about its minimal RAM footprint (and it is really minimal compared to other system libraries). Quote:
At this point, my usual canon starts: The problem is that the *interface* of the dos.library is not properly defined to handle such cases, and it is too late to change an interface if we have implementations in the wild that instead depend on the actual implementation details since the documentation of this interface was so lousy (and in case of the dos.library, that was unfortunately really the case). |
||
08 April 2024, 23:50 | #37 |
Registered User
Join Date: Apr 2013
Location: Norway
Posts: 258
|
Yeah the idea with the goal makes sense, Thomas.
But is the installation the same regardless of rom or disk based installations? I mean, will all the same files be copied to the hard drive, or will something be excluded because it’s in the rom “anyway” ? For example classes, libs, handlers and so on? |
09 April 2024, 07:22 | #38 | |
Registered User
Join Date: Jan 2005
Location: Umeå
Age: 44
Posts: 938
|
Quote:
1. BlizKick ROM 2. FastExec 3. Disable mmu.library FastExex does the same as MuMove4K and MuFastZero - move the library base of exec.library to fastmem and optionally move SSP too - this is what gives the snappy feel, but without using the MMU. Not enabling the MMU on the 030 (with a fairly complicated config) will give you anywhere from 10-20% extra performance when doing things that uses some memory bandwidth, like networking, extracting archives etc. |
|
09 April 2024, 09:52 | #39 | |||||||||||||||
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,359
|
Quote:
Quote:
However, as stated above (several times now) the open count of the library (as shown by ARTM) is nonzero. Quote:
Quote:
I still observe an open count of 4 under WB (how many times i wrote this already ?) - and this is without either BindDrivers being run nor RTG as none of them is used in my system. So who are other clients ? Quote:
Quote:
Quote:
Quote:
Perhaps the design isn't really stuck. The library itself has nothing that can not be moved (once it is no longer open). The database can be put in fastmem if said fastmem is found before database is allocated. Is there a reason why expansion can't find memory first, then write the config down ? If yes, expansion can still reallocate current data right when fastmem is finally found. Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
|
|||||||||||||||
09 April 2024, 10:59 | #40 |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,327
|
|
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Slow performance with AmigaOS 3.1.4 in WinUAE 4.2.1 | matsp888 | support.WinUAE | 15 | 13 January 2020 03:15 |
Accurate performance? | epoxxy | support.WinUAE | 1 | 25 October 2015 14:22 |
Getting more performance out of my A1200 | Devlin | support.Hardware | 4 | 18 December 2013 18:17 |
PSPUAE Performance | tonyyeb | support.OtherUAE | 73 | 27 January 2011 16:45 |
How do I get the best WB performance? | Rabbit80 | support.Apps | 27 | 01 July 2009 11:29 |
|
|