Re: BigRamPlus arrived
Ingo Jürgensmann dixit:
>Or even easier: we know that memory on accelerator cards will be
>located at 0x08000000 (didn't count the zeros ;) and should have the
Oh, please not…
Geert Uytterhoeven dixit:
>On Sun, Dec 8, 2013 at 10:58 PM, Michael Schmitz
>> It already is (has to be, due to lack of sparse mem support). And the kernel
>> lives in ST-RAM pretty much always.
>
>I know it is, but TT-RAM should be faster, right?
The kernel can also be loaded to TT-RAM by some of the
bootloader versions, IIRC… but AFAIR then it could not
use the ST-RAM because it assumed that the first chunk
was the lowest, or something.
All of these (plus the sheer amount of m68k variants –
there are the VME, Q40/Q60, and even more, still) just
cry for flexible memory layouts, in priority, order of
allocation, speed, physical layout etc. (and hardware‐
specific allocation rules like framebuffer must reside
in ST-RAM).
>>> Alternatively, it could be done automatically, by the kernel
>>> measuring read (and/or write) performance of the different memory
>>> chunks in a loop similar to the delay loop calibration.
>As long as you read enough data, it should be OK.
Sounds interesting, as long as someone defines “enough” ☺
bye,
//mirabilos
--
Solange man keine schmutzigen Tricks macht, und ich meine *wirklich*
schmutzige Tricks, wie bei einer doppelt verketteten Liste beide
Pointer XORen und in nur einem Word speichern, funktioniert Boehm ganz
hervorragend. -- Andreas Bogk über boehm-gc in d.a.s.r
Reply to: