Bigger RAM disc

At the minute I can’t make RAM disc bigger than 128MB <—which is amusing as that is the minimum amount of RAM the Iyonix shipped with…

With 1GB RAM on board I would like it to be much bigger i.e. big enough to build RISC OS using a RAM disc.

This would I suspect give a significant speed increase…

Is this trivial or am I (again… ahem!) asking for too much?

It looks like the maximum size is specified by the kernel, so although it looks trivial to change the limit it might not be trivial for you to switch to a ROM image which supports the larger size :)

On an Iyonix I’m not sure if you’d get much of a speed gain from moving the source tree into a RAM disc – I’d expect the hard disc to be fast enough to keep up with the CPU.

You could always experiment by moving part of the source tree into a RAM disc – e.g. the BuildSys, Library and Export folders. In theory all you’d have to do is update RiscOS.Env.!Common to point to the new locations.

IIRC you need to take care with the amount of free logical address space this will leave; you only have 4GB to play with. You need to fit your desired maximum application Wimp slot size plus all other dynamic areas into the remainder.

Bulk transfer speed is, embarrassingly, about 1/5th the speed of the DMA-enabled HD access on the IYONIX pc, and if memory serves the RAM disc is still – bizarrely – uncacheable which is rather stupid. That said, I had a hacky prototype somewhere which used the AAU for transferring to/from the RAM disc and that gave a ~20-fold increase in the bulk transfer speed which was rather nice.

Hook that into Wimp_TransferBlock and we might be getting somewhere ;-)

if memory serves the RAM disc is still – bizarrely – uncacheable which is rather stupid

I think you’re correct! The code (around line 1645 in Kernel.s.NewReset) checks bits 12-15 of the ARM ID register (i.e. the top 4 bits of the primary part number). If the bits are &A, it assumes it’s running on a StronARM and makes the area cacheable, else it makes it uncacheable.

Apart from the check being complete nonsense and subject to failure, can anyone think of any reason why this check exists? Surely it’s safe for the RAM disc to be cacheable on all machines.

I believe the reasons for this (and the fact that the screen dynamic area is similarly marked uncacheable) is to avoid hammering the data cache with large quantities of data that are loaded just once before being replaced. Since FileCore does buffered file IO, all the transfers that RAMFS performs will use LDM/STM even if the file is being accessed bytewise, so there is very little if anything to be gained.

The reason why there’s a specific check for StrongARM is because of a bug in the StrongARM core – it’s unable to do burst memory accesses to uncached locations, which really is a performance hit. I believe this does not affect other earlier or later cores.

Logical address space exhaustion is a real problem on modern machines that have bags of RAM - the fact that Iyonixes had to ship with dynamic area clamping enabled is evidence of this. Anything that doesn’t need to be accessed by multiple applications or by interrupt handlers or callbacks should not be using up precious global address space. It really didn’t help that RISCOS Ltd actually encouraged developers to make more use of dynamic areas for years – that was basically just a workaround for the fact that people had started fitting more than 28 MB to 26-bit machines, at which point moving to a 32-bit OS starts making sense. Ideally the application slot should be at least as large as the fitted RAM so that the user can allocate most of it to the application of their choice. Having said that, it was difficult to justify raising the application slot size to 1GB for Iyonix because of address space exhaustion – many applications have trouble with top-bit-set addresses, so in practice that only leaves 1GB for dynamic areas – but maybe the situation has changed since then? You can easily try turning off the dynamic area clamps and seeing how much software breaks.

RAMFS is actually quite a good candidate for changing to use an application slot instead of a dynamic area. However I think the memory copy code would need some work since AFAIR Wimp_TransferBlock (the only current API for moving data between application slots) uses an intermediate buffer in shared memory, so you’d be doubling the data transfer time. This could be avoided if a memory-to-memory DMA controller were used instead, as it can transfer data without having to reprogram the MMU - though obviously this requires a reasonably modern CPU.

We originally planned as a later phase of the Iyonix development project, amongst other things, to add use of memory-to-memory DMA to the OS in any area where large amounts of data copying is used – so in memcpy(), Wimp_TransferBlock and several parts of the filing system stack, at least. On XScale, the HAL implementation of this would have used the AAC or DMA controller depending upon the physical addresses used. Sadly, that particular phase got cancelled.

using !Memphis it is possible to get a very large ramdisk. It even can save a copy of the contents when you quit. That way you keep what was in the ramdisk.