Simulating having less memory

I am doing some benchmarking, and I want to isolate whether the speed differences I am seeing are down to the disc interface speed or the RAM. I have a machine with 4GB of RAM and a different one with 2GB of RAM. I want to reserve 2GB out of the 4GB of RAM on the first machine so that it effectively has the same amount of RAM as the other machine, so that I can compare the performance more accurately.

The software I am testing is OSMConvert
which we use to convert OpenStreetMap data. Depending on the machine it can take several days to convert data, so the performance is important. It also uses a lot of RAM, and that could be a big factor in the differences from one machine to another.

My first attempt to reserve 2GB of RAM “out of use” was to write a short piece of BASIC which created 16 dynamic areas, each of 128MB in size. Unfortunately OSMConvert ran out of memory while processing the data. This is despite the fact that it happily processed the same data on the machine that has 2GB of RAM.

I wondered whether my allocating the dynamic areas had used up so much logical address space that it had been impossible for OSMConvert to create its own dynamic areas as expected. So I tried using the new PMP dynamic areas

I wrote some BASIC to allocate a single PMP area with no logical address space and allocate 2GB of RAM to it. You can download the BASIC to try it yourself.

The area clearly gets reserved and can be seen in the Task Manager, but the operating system quickly starts behaving strangely. I was able to run Draw and draw a few lines, but if I ran NetSurf it crashed with an address exception. Fairly swiftly the sprites on the desktop started disappearing.

Is there a fault with my BASIC or a fault in the OS (5.29)? I must admit I’m not sure about the handler routine which I created.

Why not create a 2GB RAM disc?

Interestingly the same problem happens if I do that! Steps taken:

1. Reset machine
2. Open Task Manager and drag RAM disc slider to the maximum (which is 2GB)
3. Open hard disc.
4. Double-click on directory to access the application I want to run.
5. Get Error “Internal error: abort on data transfer at &FC17977C”

I didn’t even run the application: that error occurred even before the Filer displayed the directory.

I did notice that when I previously got errors various sprites started disappearing from the filer windows, as though the Wimp sprite pool had gone wrong. The error may have been triggered therefore by the IconSprites command when the Filer booted the application which was sitting inside the directory I was opening.

On the machine I am only running a VNC Server on boot. The hard disc is shared via ShareFS. Pinboard is running. That’s about it. Raspberry Pi 4, RISC OS 5.29.

Can anyone else reproduce this?

Tried this on a CM4 4GB (16GB eMMc) running at 2GHz on a Waveshare Mini-B IO board. No error. Running RISC OS 5.29 1 Feb 2023 (the first ROM to get eMMc working).

Thanks for the testing, Chris, much appreciated. I would have been surprised if Jeffrey hadn’t tested with a 2GB RAM Disc — on an old thread he referred to keeping a lower limit because of a problem with FileCore, so you’d think it was tested thoroughly when the limit was raised.

My ROM is dated 25-Jan-23, but I know that it’s a custom ROM to support some hardware that I am testing. I will talk to the person who supplied it to me, in case there is an issue with it.

It would be useful to know whether you get any issues running my example BASIC, Chris?

PS I modified my BASIC to grab only 512MB of RAM. I reset the machine and repeated these steps:

1. Run BASIC to grab 512MB RAM into a PMP area
2. Run NetSurf
3. Quit NetSurf

It was only after the fourth time of running the BASIC, when 2GB had been grabbed in total, that I got the error.

Some software does not like running in high memory, i.e. above 2GB and reserving a 2GB RAM disk does not ensure that only low memory is presented to an application (I think). StrongEd would not run on a 4GB machine until it was fixed I seem to remember

There is a difference between logical and physical memory. These days the RAM disc only uses a 1MB logical window to view its memory allocation, so allocating a very large RAM disc should have no impact on whether other applications see high logical addresses. All Wimp applications still get a logical address space starting at &8000.

I suppose there may be a few applications which do clever things with physical memory, but that would be very rare. the vast majority of the operating system only deals with logical addresses.

Not having a 4GB machine I cannot test, but to me the handler in ReservePMP looks wrong:
- The error message should be zero terminated.
- OS_GenerateError only returns if X set – not documented where it goes if not set.
- DA handlers should set r0=> error block, then return with V set. r3 probably best zeroed as well.

Possibly not relevant to your problem though!

I wrote some BASIC to allocate a single PMP area with no logical address space and allocate 2GB of RAM to it. You can download the BASIC to try it yourself.

That ran without any noticeable issue on the 4GB RPi400, the 2GB Reserve DA is created and the machine remained stable, even Iris ran properly.

A 2GB RAM disc did not mess up either.

The ROM is 19Jan23.

Thank you David for confirming. Yes, it definitely looks like there’s a problem with the ROM that I am using.

Thank you, Martin, it’s a long time since I used the BASIC assembler! It’s annoying the PMP blocks require a handler even when you’ve set the non-draggable flag. I imagine a handler has to be in RMA rather than application space, but it doesn’t say.

I rather struggled creating a PMP block in the first place until I found a thread from Jeffrey which explained things better than the current wiki page. Things I had not appreciated included:

• need for a handler
• the fact the logical space must start as zero
• the need to set bit 8 of the area flags as well as bit 20.

Since this is a Pi, you can limit the amount of memory in config.txt with:

total_mem=2048

Since this is at the bootloader level, it should be identical to having less physical RAM.

Thanks Theo. Someone else also suggested that to me. It doesn’t seem to work on the machine I am using, however. Perhaps it’s because it’s a Compute Module 4 — it may not boot quite the same way as the SD card plugs into the IO board.