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

91–100 of 119 posts

Re: Async hazard: MMAP is blocking IO

#91

Post by jcalvinowens »

krilovsky wrote: post #86
jcalvinowens wrote: post #83

Earlier quoted context omitted.

> If it's not a single disk system, not necessarily. Again, you miss the point. 95%+ of Linux systems are single disk. That's the expected case. >> If you've hit EMFILE > I'm not sure why you keep sticking to this example You brought this up initially, saying it was difficult to handle. I'm demonstrating that you're wrong, it's actually quite trivial to handle. Handwaving about "edge cases" is FUD, if you have some s…

> Again, you miss the point. 95%+ of Linux systems are single disk. That's the expected case. I specifically added ENOSPC as an example that's relevant on single disk systems as well. Regardless, I thought we were talking about 95% of usecases in relation to implementations, not runtime systems, but even if we're talking about runtime systems, I'm not sure where you're pulling that 95% number from (or why you felt th…

> I have no idea why you added this remark telling me that I should try it, when you clearly didn't.

You are hilariously hostile here, I don't get it. si_errno is the second field in the struct after si_signo, saying "si_errno etc." is obviously in reference to the rest of the fields in the structure...

Re: Async hazard: MMAP is blocking IO

#93

Post by noctune »

rbanffy wrote: post #41
a-dub wrote: post #26

Earlier quoted context omitted.

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 ker…

Making it work asynchronously would require the compiler to split the memory access into two parts, a non-blocking IO dispatch and a blocking access to the mapped address. The OS would need to support that, however, and the language would need to keep track of what is a materialised array and what’s not.

I think you could make by with some kind of async memory-touch system call, i.e. "page in this range of memory, notify me when finished". The application would have to call this on blocks of the mmap prior to actually reading it.

This of course means you lose some of the benefits of mmap (few system calls, automatic paging), but would maybe still be beneficial from a performance perspective.

Re: Async hazard: MMAP is blocking IO

#94

Post by malkia »

jcalvinowens wrote: post #65
malkia wrote: post #60

Earlier quoted context omitted.

Are you saying that I can get somehow an error during "strlen" post "read()" - is this what are you saying? Because what I'm saying is that with "mmap" you can get that.

Absolutely: if the user page you read into experiences an uncorrectable ECC error in strlen(), you get SIGBUS. Friends don't let friends write code to attempt recovery from hardware failures.

ECC errors of a magnitudes lower chance to happen than broken file system

Re: Async hazard: MMAP is blocking IO

#95

Post by rini17 »

akira2501 wrote: post #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…

I looked into it (as part of optimizing LLM memory throughput) and hugepage file-backed maps aren't supported under linux. Only anonymous mappings.

Re: Async hazard: MMAP is blocking IO

#96

Post by scienceplease »

cbsmith wrote: post #43
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…

I'm surprised this is seen as a liability of mmap rather than a cooperative scheduler that isn't using native kernel threads. This is the deal you make with the devil when you use cooperative scheduling without involving the kernel, so I'm surprised it is news to people working with cooperative schedulers. These faults can happen even if you never explicitly memory map files (particularly since executables and shared…

> cooperative scheduler that isn't using native kernel threads

Can anyone point me towards cooperative thread schedulers that use native kernel threads? Would this effectively mean implementing a cooperative model on top of pthreads?

Re: Async hazard: MMAP is blocking IO

#97

Post by [deleted] »

jerf wrote: post #34
guerrilla wrote: post #6

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

The term "blocking" has diverged between various communities and it is important to recognize those differences or you'll have dozens of people talking past each other for hundreds of messages as they all say "blocking" and think they mean the same thing, and then get very confused and angry at all the other people who are so obviously wrong (and in their context, they are) but just can't see it. It is obvious that a…

[deleted]

Re: Async hazard: MMAP is blocking IO

#98

Post by jsnell »

scienceplease wrote: post #96
cbsmith wrote: post #43

Earlier quoted context omitted.

I'm surprised this is seen as a liability of mmap rather than a cooperative scheduler that isn't using native kernel threads. This is the deal you make with the devil when you use cooperative scheduling without involving the kernel, so I'm surprised it is news to people working with cooperative schedulers. These faults can happen even if you never explicitly memory map files (particularly since executables and shared…

> cooperative scheduler that isn't using native kernel threads Can anyone point me towards cooperative thread schedulers that use native kernel threads? Would this effectively mean implementing a cooperative model on top of pthreads?

The term to search for prior art is user-mode scheduler / scheduling. Basically you add additional kernel features that allow making some scheduling decisions in the application, it's not something you'd just build on a vanilla pthreads implementation.

Examples:

Windows 7 UMS: https://learn.microsoft.com/en-us/windows/win32/procthread/u...

google3 fibers / switchto: https://www.youtube.com/watch?v=KXuZi9aeGTw

Re: Async hazard: MMAP is blocking IO

#99

Post by Retr0id »

dbaupp wrote: post #68
Retr0id wrote: post #10

> This is thus a worst case, the impact on real code is unlikely to be quite this severe! I think the actual worst-case would be to read the pages in a (pseudo-)random order.

(Author here.) Good point. Do you think the difference will be observable? Will it be observable on an SSD (vs. HDD)?

I think so, yes - only one way to find out, though!

Re: Async hazard: MMAP is blocking IO

#100

Post by krilovsky »

jcalvinowens wrote: post #91
krilovsky wrote: post #86

Earlier quoted context omitted.

> Again, you miss the point. 95%+ of Linux systems are single disk. That's the expected case. I specifically added ENOSPC as an example that's relevant on single disk systems as well. Regardless, I thought we were talking about 95% of usecases in relation to implementations, not runtime systems, but even if we're talking about runtime systems, I'm not sure where you're pulling that 95% number from (or why you felt th…

> I have no idea why you added this remark telling me that I should try it, when you clearly didn't. You are hilariously hostile here, I don't get it. si_errno is the second field in the struct after si_signo, saying "si_errno etc." is obviously in reference to the rest of the fields in the structure...

> You are hilariously hostile here, I don't get it.

I apologise if it came out hostile. That was not my intention. I was in a bit of hurry when I made the edit, and I just trying to expand my comment in response to your edit, and explain that non-I/O and non-disk SIGBUS errors sometimes look exactly like disk and filesystem errors that return EIO (not just signum being SIGBUS, but also si_code being set to BUS_ADRERR, etc.), so looking at the siginfo_t fields alone wouldn't be enough to diambiguate.

Then there's the address field, which can be probably be used in combination with parsing /proc/self/maps, but my point in that comment was that the information on the manpage alone wouldn't have helped people trying to implement a handler correctly.

In any case, I already described a scenario where crashing would be the wrong thing to do IMO, which you seemed to ignore. Even in scenarios where crashing is reasonable, I'm sure there's a solution for every edge case that I would bring up, but I never said that it was impossible, so I'm not sure why asking me to list every possible edge case is relevant when my point was just that there are edge cases, and that you'd need to consider them (and they would be different for different apps), thus making an implementation not trivial. That doesn't mean that it's necessarily difficult, just that it might be a more complex solution when compared to dealing with a failing VFS operation.

As it seems that we've reached an impasse, I'll just say that simplicity depends on the context and is sometimes a matter of personal taste. I don't have anything against mmap, and I was only trying to argue that there's a trade-off, but you are of course free to disagree and use mmap everywhere if that works for you.

I don't think I have anything more to add to what I already said, and I'm sorry again if you felt personally attacked, or that I had something against mmap and trying to spread FUD.

Post reply on HN