Re: Multiple Memory Chunks
On Sat, Aug 10, 2013 at 11:00 PM, Ingo Jürgensmann
<ij@2013.bluespice.org> wrote:
> Am 10.08.2013 um 13:46 schrieb Geert Uytterhoeven <geert@linux-m68k.org>:
>>> So, apparently the second FastMem chunk is ignored by the kernel itself. Is
>>> there a way to make use of the additional 12 MB RAM? Although it's not as
>>> fast as the 32bit memory on the accelerator card (64MB), it is still faster
>>> than swapping to/from disk.
>> If you reverse the order of the chunks, it will use both. Unfortunately the
>> kernel will be in the slowest chunk.
>
> Yes, and I would like to avoid this, of course. ;-) It really slows down the machine and you can even feel it... ;)
We may also use the slow mainboard RAM (I get ca. 12 MiB/s) as a fast swap
device.
For Z2 RAM we have our good old z2ram driver, but in the mean time there's a
more generic solution in drivers/mtd, IIRC.
>>> Especially this becomes important when we want to put BigRamPlus RAM
>>> extensions into Amigas. Those are 256MB RAM extensions via ZorroIII bus and
>>> the port would highly benefit from supporting multiple memory chunks. Is
>>> this possible?
>> I'd expect a Zorro III RAM expansion to end up at either 0xff000000 or
>> 0x40000000, which is a higher address than your other RAM, so it
>> should be OK.
>
> Except that the ZorroIII RAM will be 4-6x slower than the RAM on the accelerator cards.
So this is also a candidate for swap? Does anyone have benchmark results?
I found that ZoRAM does 12 MiB/s.
BTW, http://www.bigbookofamigahardware.com/bboah/product.aspx?id=1936 claims
it's only guaranteed to work with the original daughter board, and thus may fail
with '060 accelerators.
>> Now why do you have a memfile like this: a long time ago, the m68k kernel
>> used its own mapping code for system RAM, where virtual and physical
>
> Remember that there were problems with loading 3.2.0-4-amiga without the memfile.
Yes, going out of memory when allocating the page table arrays? That won't
improve when adding 256 MiB of Z3 RAM in the far end of the physical
address space...
>> addresses differed. This was needed as unlike on PC, (a) memory doesn't
>> always start at address zero, and (b) memory isn't always contiguous.
>> Hence we used the MMU to map all memory chunks next to each other,
>> starting at virtual address zero.
>>
>> With the unification of memory mapping across the different architectures,
>> ouw own mapping code (and this feature) was lost.
>> Due to lack of manpower, we (IIRC Roman Zippel) switched to the
>> simplest memory model, where virtual == physical, but where memory
>> doesn't have to start at zero.
>>
>> However, it should be possible to revive the virtual mapping using
>> generic code, as some of the big NUMA systems also needed it.
>
> Yeah, that would be great...
>
> But we would still have the problem with the loading the kernel to the proper memory chunk, i.e. the fastest.
> AmigaOS has the concept of priorities for memory chunks. The memory on Cyberstorm MK2 accel cards have a priority of 40 whereas normal FastRAM on the mainboard has a priority of 10 (IIRC). The Amiga memory manager automatically selects the priority based on actually memory speeds on each boot, as stated at http://amigadev.elowar.com/read/ADCD_2.1/Hardware_Manual_guide/node00D2.html and http://amigadev.elowar.com/read/ADCD_2.1/Hardware_Manual_guide/node00D4.html outlines that the fastest memory will be located between the mainboard memory and the ZorroIII memory, as you said above.
> So the trick is get the kernel loaded in the fastest memory chunk and then reorder the other chunks accordingly. I think it's easier to have the kernel do the right thing[TM] than to rely on a fixed version of amiboot. That way we could use the memfile to determine where the kernel will get loaded (fastest chunk) by amiboot.
The NUMA code should also take into account priorities, at least for CPU
affinity (although we have only one CPU).
>> See mm/Kconfig, which offers DISCONTIGMEM (what we use),
>> SPARSEMEM (what you need), and FLATMEM.
>>
>> Note that SPARSEMEM may give better performance with
>> BigRamPlus, as there's probably a huge gap between its physical
>> address and the addresses of your other memory chunks.
>
> So, to test this, I could edit that file, make the change and recompile the kernel and see whether amiboot loads the kernel to 0x08000000 and the kernel still uses the 12 MB memory on the mainboard?
Unfortunately it's not that simple. I haven't checked the details, but
I think we'll
have to change other parts in arch/m68k/mm, too. Definitely the check to
ignore blocks with lower addresses has to go ;-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Reply to: