Ingo,
As I understood, the approval of approx. 500.- Euro to buy RAM expansions for our buildds is given. Regarding to Adrian the DPL asked for a quote to issue the money. So, the question is: how to proceed?The current situation:We currently have 6 Amigas that have ZorroIII slots, namely: crest, elgar, kullervo, arrakis, spice, vivaldi. Elgar and crest are remodded Desktop Amigas built into Tower cases. That might work, but is not guaranteed. Would both be brought back into original Desktop cases with genuine riser cards, both ought to work fine as well. Another "problem" is the kernel lacking SPARSEMEM support. There was some discussion on this mailing list some weeks ago about this and additionally I asked Geert in private what needs to be done to get this into the kernel. He said it would probably mean a week of full time work when doing this on Aranym, more when doing it on real hardware, but it is doable and most likely needed to keep Debian on m68k alive.
There's no reason why the sparsemem work has to be done on real hardware, is there?
What precisely is the memory layout when including the bigmem chunk?
Technically, despite whether the card work in Elgar and Crest or not, the BigRamPlus should work in at least 4 buildds and should be usuable by using a memfile. The downside of this will be that the kernel will then be located inside of the slower ZorroIII memory. Memory speeds will most like be like 60 MB/s for accelerator cards and 12-15 MB/s for ZorroIII memory. ZorroIII memory will still be faster than swapping to disk (approx 2-2.5 MB/s max). Therefore the extra 256M will benefit those hosts anyway, but slow ZorroIII memory will slow down all operations when the kernel lies in that region. That is why we need the SPARSEMEM support with MMU to rearrange the memory chunks. In addition to this we would be able to use the extra memory on the motherboard as well, which can give us upto 16MB on top.
Unlike the situation on Atari hardware (kernel in FastRAM is what I am comparing here), the only impact will be slower kernel code execution. The RAM extension should otherwise work off the bat, right?
My proposal: There are two ways, actually:a) we ask for a the manufacturer Individual Computers for a quote of 6 BigRamPlus expansions so we can equip all capable ZorroIII hosts we currently have. When given approval from DPL we buy all of them, regardless of how far SPARSEMEM support in kernel is at that time.
That would be my preference. We are hardly squeezed for kernel memory on the buildds - process memory is what tends to get tight.
b) we buy just one BigRamPlus to see if it works as expected and in order to test how SPARSEMEM works, and buy later the other cards, without knowing when we actually buy them.Are there other buildds that aren't maxed out currently and need some memory as well?What are your thoughts? Are there other ideas how to spend the money?Who is volunteering for SPARSEMEM support? My understanding is, that Atari will benefit from that as well.
In order to fully support kernel in FastRAM with ST-RAM available to processes, that would be required indeed. In order to support basic functionality, memory for use by the late ST-RAM allocator can be conveyed to the kernel using ioremap. I'd give that latter option a shot first to see whether TTs can be supported again.
Sparsemem could be independent from getting Atari to boot kernels in the FastRAM chunk, is what I am trying to say.
(I suck rocks through straws at memory management code - did I mention that before? Not volunteering ...)
At least for my 4 Amigas (Elgar, Arrakis, Spice & Vivaldi) I might be able to buy the cards all by myself, so if there are other machines that need that money better then that's fine for me. I know that Wouter has a A4000 in his collection, without knowing what's actually inside of that machine. Maybe, when just a network card is missing, then a better investment would be to buy one for that host?
With increasing demand on virtual memory size, RAM expansions seem to be the best option IMHO. Good on you for getting approval for the hardware upgrade, now let's see that put to use in solving the memory pressure problems.
Cheers, Michael
Your opinions?
--
Ciao... // Fon: 0381-2744150
Ingo \X/ http://blog.windfluechter.net
gpg pubkey: http://www.juergensmann.de/ij_public_key.asc