Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Async hazard: MMAP is blocking IO

huonw.github.io

Post reply on HN
Print view View original

21–30 of 119 posts

Re: Async hazard: MMAP is blocking IO

#21

Post by mjb »

tux3 wrote: post #12
lowbloodsugar wrote: post #11

- 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)

Modern data center networks offer RTTs about 100x lower than hard drive latency, and comparable to local SSD. It depends, of course, how far over the network you're going, and how fast the other side responds, but <100us is very achievable.

Re: Async hazard: MMAP is blocking IO

#22

Post by icedchai »

magicalhippo wrote: post #17
usefulcat wrote: post #14

Earlier quoted context omitted.

> 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.

Do you consider reading from a normal array (one not backed by a memory mapped file) to also be blocking?

Re: Async hazard: MMAP is blocking IO

#23

Post by danarmak »

magicalhippo wrote: post #17
usefulcat wrote: post #14

Earlier quoted context omitted.

> 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.

No, if the memory-mapped page you're accessing is in RAM, then you're just reading the RAM; there is no page fault and no syscall and nothing blocks.

You could say that any non-register memory access "blocks" but I feel that's needlessly confusing. Normal async code doesn't "block" in any relevant sense when it accesses the heap.

Re: Async hazard: MMAP is blocking IO

#25

Post by magicalhippo »

icedchai wrote: post #22
magicalhippo wrote: post #17

Earlier quoted context omitted.

It still blocks. It just completes orders of magnitudes faster.

Do you consider reading from a normal array (one not backed by a memory mapped file) to also be blocking?

In the languages and platforms I use, absolutely yes. Do you have some examples where a normal memory read is async?

Re: Async hazard: MMAP is blocking IO

#26

Post by a-dub »

mjb wrote: post #9

I like this point - it's no secret that mmap can make memory access cost the same as an IO (swap can too) - but the interaction with async schedulers isn't immediately obvious. The cost can, sometimes, be even higher than this post says, because of write back behavior in Linux. Mmap is an interesting tool for system builders. It's super powerful, and super useful. But it's also kind of dangerous because the gap betwe…

it outsources buffer management and user thread i/o scheduling to the kernel. for some use cases it's a great way to simplify implementation or boost performance. for others it may not perform as well.

the blog post points (in my mind) at some more general advice when programming which is not to mix and match paradigms unless you really know what you're doing. if you want to do user space async io, cool. if using kernel features tickles your fancy, also cool.

mixing both without a deep understanding of what's going on under the hood will probably give you trouble.

Re: Async hazard: MMAP is blocking IO

#27

Post by magicalhippo »

danarmak wrote: post #23
magicalhippo wrote: post #17

Earlier quoted context omitted.

It still blocks. It just completes orders of magnitudes faster.

No, if the memory-mapped page you're accessing is in RAM, then you're just reading the RAM; there is no page fault and no syscall and nothing blocks. You could say that any non-register memory access "blocks" but I feel that's needlessly confusing. Normal async code doesn't "block" in any relevant sense when it accesses the heap.

When dealing with async I think it is very relevant to think of exactly the points where control can be switched.

As such a regular memory read is blocking, in that control will not switch while you're doing the read (ie your not doing anything else while it's copying). This is unlike issuing an async read, which is exactly a point where control can switch.

edit: As an example, consider synchronous memory copy vs asynchronous DMA-based memory copy. From the point of view of your thread, the synchronous copying blocks, while with the DMA-based copying the thread can do other stuff while the copying progresses.

Re: Async hazard: MMAP is blocking IO

#28

Post by icedchai »

magicalhippo wrote: post #25
icedchai wrote: post #22

Earlier quoted context omitted.

Do you consider reading from a normal array (one not backed by a memory mapped file) to also be blocking?

In the languages and platforms I use, absolutely yes. Do you have some examples where a normal memory read is async?

Your definition of blocking is a bit different from my own. Synchronous is not always blocking. If the data is there, ready to go, there is no "blocking."

If you consider all memory reads to be "blocking", then everything must be "blocking". The executable code must, after all, be read by the processor. In an extreme case, the entire executable could be paged out to disk! This interpretation is not what most people mean by "blocking."

Re: Async hazard: MMAP is blocking IO

#29

Post by [deleted] »

magicalhippo wrote: post #17
usefulcat wrote: post #14

Earlier quoted context omitted.

> 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.

[deleted]

Re: Async hazard: MMAP is blocking IO

#30

Post by mwcampbell »

pengaru wrote: post #20

water is wet

Nobody automatically knows everything, and we have limited energy for drawing inferences based on what we do know. So the material covered in this post isn't obvious to everyone in its target audience, especially since Rust has had some success in making systems programming more approachable to inexperienced programmers, which is a good thing.
Post reply on HN