Sir how is this faster than directly writing onto the file on disk ? Here you page it in, then write on physical memory and then it eventually has to write back in disk, so how is this faster ? Sorry if this is a dumb question and I understand the queuing part but, in both cases, you need to move the disk read/write heads which is going to take up time. So ain't this more indirect and should take more time ?
The only speed increase is due to the fact that changes to the file don't require a system call. However, you're right that the pages need to be both read in and written out whether or not the file is memory-mapped. It provides a different interface for the application that may be more convenient. It can sometimes reduce the amount of copying that's done as well.
There are other benefits, like for example if you mount the file to the same address space every time, you can store self referential pointers directly in a file, and they’ll stay valid on subsequent loads of the file
I understand that you can optionally `msync` your write if you want to ensure it's written back to disk, but as you mentioned otherwise is up to the kernel to decide when to write it back to disk. For this same reason, I understand that database engines try to avoid `mmap` since it could result in dirty writes or write before a transaction completes (if the kernel decides to write back to disk). Do you know what alternatives do they have to map files to memory without having to worry on the kernel writing them back to disk when the engine doesn't want to yet? Thanks in advance.
There's a flat address space and mmap must map somewhere within that address space. Before the mapping, trying to access memory at that address will cause a page fault (assuming it's unmapped). Afterwards, access will succeed.
This is the best explanation I've seen so far. Straight to the point
NICE
You're like the Clint Eastwood of programmers
Sir how is this faster than directly writing onto the file on disk ? Here you page it in, then write on physical memory and then it eventually has to write back in disk, so how is this faster ?
Sorry if this is a dumb question and I understand the queuing part but, in both cases, you need to move the disk read/write heads which is going to take up time. So ain't this more indirect and should take more time ?
The only speed increase is due to the fact that changes to the file don't require a system call. However, you're right that the pages need to be both read in and written out whether or not the file is memory-mapped.
It provides a different interface for the application that may be more convenient. It can sometimes reduce the amount of copying that's done as well.
There are other benefits, like for example if you mount the file to the same address space every time, you can store self referential pointers directly in a file, and they’ll stay valid on subsequent loads of the file
I understand that you can optionally `msync` your write if you want to ensure it's written back to disk, but as you mentioned otherwise is up to the kernel to decide when to write it back to disk. For this same reason, I understand that database engines try to avoid `mmap` since it could result in dirty writes or write before a transaction completes (if the kernel decides to write back to disk).
Do you know what alternatives do they have to map files to memory without having to worry on the kernel writing them back to disk when the engine doesn't want to yet?
Thanks in advance.
Neil thank you so much for this!
Happy to provide it.
thank you so much for your videos!
Amazing explanation
Does mmap increase a process' address space? If not, which segment is it stored in the memory?
There's a flat address space and mmap must map somewhere within that address space. Before the mapping, trying to access memory at that address will cause a page fault (assuming it's unmapped). Afterwards, access will succeed.
Thanks for helping me on my programming course! Did you really write that all on glass and mirrored the video?
Yes. See ruclips.net/video/S-rDH4O5CsI/видео.html for a "Making of" video that shows the process in detail.
@@NeilRhodesHMC Loved this video format!
Great explanation!
very nice professor
GOLD
Thanks !
hey uncle where does your voice coming from?I cant hear anything..pfff.lol
If only there were Chinese subtitles
5head
Thanks!