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
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
Archive:
http://lists.debian.org/[email protected]
