- register
- shadow register
- L1
- L2
- L3
- RAM
- GPU/SPU/RSP
- SSD
- Network
- HDD
The line is drawn depending on what you are doing and how.
Edit: moved Network above HDD. :-)
Async hazard: MMAP is blocking IO
11–20 of 119 posts
Re: Async hazard: MMAP is blocking IO
#12- register - shadow register - L1 - L2 - L3 - RAM - GPU/SPU/RSP - SSD - Network - HDD The line is drawn depending on what you are doing and how. Edit: moved Network above HDD. :-)
I would put networks above HDDs (depending on how many miles you need to send your emails)
Re: Async hazard: MMAP is blocking IO
#13No secret. Reading from memory is synchronous and always has been, at least in a normal computer. (Sometimes I think of how you could fit a fancy memory controller in a transport triggered architecture but that’s something different)
On Linux, you might be able to use userfaultfd to make it async...
I don't see how that would work. The memory access causing the page fault still blocks, but now another thread handles paging in the requested data. So without coordination between those two, nothing really changes. Sounds easier to just use nonblocking reads directly.
Thanks for the pointer to userfaultfd. Didn't know that existed.
Re: Async hazard: MMAP is blocking IO
#14Earlier quoted context omitted.
GP is aware. mmap makes files act like memory. Memory is always synchronous, thus blocking, so mmaped files are always blocking. I'm surprised OP even found this surprising. It should be completely obvious.
At first I thought the title meant the mmap() call itself blocks, which I figured could be slightly surprising. But it seems they're referring to I/O on the mapped file? I'm also baffled, how could it possibly not block?
> how could it possibly not block?
When the bytes being read are already in the cache. Hence the later part of the article where the author shows that reading mapped memory can be significantly faster.
Re: Async hazard: MMAP is blocking IO
#15IMO this is a strong argument for proper threads over async: you can try and guess what will and won't block as an async framework dev, but you'll never fully match reality and you end up wasting resources when an executor blocks when you weren't expecting.
Re: Async hazard: MMAP is blocking IO
#16Earlier quoted context omitted.
GP is aware. mmap makes files act like memory. Memory is always synchronous, thus blocking, so mmaped files are always blocking. I'm surprised OP even found this surprising. It should be completely obvious.
At first I thought the title meant the mmap() call itself blocks, which I figured could be slightly surprising. But it seems they're referring to I/O on the mapped file? I'm also baffled, how could it possibly not block?
One trick is to read the file into memory at application startup. All data is paged in, so it's hot and ready to go: no page faults. In the early 2000's, I worked on a near real time system that used memory mapped I/O. At app startup, several gigabytes were read into memory. It never blocked under normal circumstances (in production) since the systems were provisioned with enough memory.
Re: Async hazard: MMAP is blocking IO
#17Earlier quoted context omitted.
At first I thought the title meant the mmap() call itself blocks, which I figured could be slightly surprising. But it seems they're referring to I/O on the mapped file? I'm also baffled, how could it possibly not block?
> how could it possibly not block? When the bytes being read are already in the cache. Hence the later part of the article where the author shows that reading mapped memory can be significantly faster.
It still blocks. It just completes orders of magnitudes faster.
Re: Async hazard: MMAP is blocking IO
#18> How do other mmap/madvise options influence this (for instance, MADV_SEQUENTIAL, MADV_WILLNEED, MADV_POPULATE, MADV_POPULATE_READ, mlock)? (Hypothesis: these options will make it more likely that data is pre-cached and thus fall into fast path more often, but without a guarantee.)
That probably should have been the first thing to try. Too mad the mmap2 crate does not expose this.
Also looking at the mmap2 crate, it chooses some rather opinionated defaults depending on which function you actually call, and it makes accessing things like HUGEPAGE maps somewhat difficult.. and for whatever reason includes the MMAP_STACK flag when you call through this path.
I feel like a lot of rust authors put faith in crates that, upon inspection, are generally poorly designed and do not expose the underlying interface properly. It's a bad crutch for the language.
Re: Async hazard: MMAP is blocking IO
#19Earlier quoted context omitted.
At first I thought the title meant the mmap() call itself blocks, which I figured could be slightly surprising. But it seems they're referring to I/O on the mapped file? I'm also baffled, how could it possibly not block?
One trick is to read the file into memory at application startup. All data is paged in, so it's hot and ready to go: no page faults. In the early 2000's, I worked on a near real time system that used memory mapped I/O. At app startup, several gigabytes were read into memory. It never blocked under normal circumstances (in production) since the systems were provisioned with enough memory.
But that requires knowing your RAM is big enough to fit the file. It can't work in general.
Re: Async hazard: MMAP is blocking IO
#20water is wet