Re: [hatari-devel] Memory mapped (mmap) image files

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On 17.8.2021 16.36, Thorsten Otto wrote:
> On Dienstag, 17. August 2021 15:20:21 CEST Uwe Seimet wrote:
> > Does anybody of you know whether accessing image files with regular file
> > system calls (like Hatari) is faster or slower than mapping those files into
> > memory (like RaSCSI)?
>
> mmap()ed files are usually much faster, because I/O is done by the kernel
> directly to your memory, without the overhead of calling file system
> functions, copying buffers around etc.

And because kernel may be able to better optimize disk accesses.  How 
much better kernel could do this depends how disconnected the 
application data
loading and its manipulation functions are, i.e.
does it load a lot of data that's not really
needed.

Kernel is in both cases going to load data from
disk to memory pre-emptively (especially with
spinning rust), so in the end that might no be
a large difference.

Also, system call overhead is nothing compared to
emulation overhead, so I'm not sure whether it's
even measurable overhead for *emulated* SW.


I think largest perf difference is related to
behavior when host system starts to run out of
memory.  With mmap(), kernel can just drop
references to non-written memory pages, but
when they're buffers that have been dirtied
by fread(), they need to be written to swap.


> However on 32bit systems, that may not
> always be possible, because you run out of virtual memory
Yes, total limit is 3.5GB, and libraries & other
memory maps and allocs already use part of that.

Another issue is portability (I assume Windows
has different APIs & behavior flags for the same
functionality).


> Also, on emulators, when you have to simulate reading data from some port
> (e.g. from the IDE interface), swap data etc, that may not be an option at
> all.

Whether the data is loaded to host memory through
fread() or mmap() page faults, does not affect
how the emulated accesses to it happen.


	- Eero