Re: Multiple Memory Chunks
On Tue, Aug 6, 2013 at 9:54 AM, Ingo Jürgensmann <ij@2013.bluespice.org> wrote:
> Apparently the linux kernel only utilizes the largest memory chunk with
> highest priority on Amigas:
That's not entirely correct: it uses all (up to the configured limit) chunks,
as long as the first chunk is the chunk with the lowest physical address.
> [ 0.000000] Ignoring memory chunk at 0x7400000:0xc00000 before the first
> chunk
>
> That's the 12 MB FastMem on the mainboard of Spice (A3000), running
> 3.2.0-4-amiga.
>
> I load the kernel with a memory file:
>
> amiboot-5.6 -m sys:work/debian/amiga/memfile -k vmlinux-3.2.0-4-amiga
> "root=/dev/sda5 video=cirrusfb:mode=800x600-60 devtmpfs.mount=1"
>
> Memfile:
> 2097152
> 0x08000000 67108864
> 0x07400000 12582912
As 0x07400000 < 0x08000000, the kernel ignores the second chunk.
>
> 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.
> 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.
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
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.
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.
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: