[GHC] #8733: I/O manager causes unnecessary syscalls in send/recv loops
#8733: I/O manager causes unnecessary syscalls in send/recv loops ------------------------------------+------------------------------------- Reporter: tibbe | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Network applications often call send followed by recv, to send a message and then read an answer. This causes syscall traces like this one: {{{ recvfrom(13, ) -- Haskell thread A sendto(13, ) -- Haskell thread A recvfrom(13, ) = -1 EAGAIN -- Haskell thread A epoll_ctl(3, ) -- Haskell thread A (a job for the IO manager) recvfrom(14, ) -- Haskell thread B sendto(14, ) -- Haskell thread B recvfrom(14, ) = -1 EAGAIN -- Haskell thread B epoll_ctl(3, ) -- Haskell thread B (a job for the IO manager) }}} The recvfrom call always fails, as the response from the partner we're communicating with won't be available right after we send the request. We ought to consider descheduling the thread as soon as sending is "done". The hard part is to figure out when that is. See http://www.yesodweb.com/blog/2014/02/new-warp for a real world example. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8733 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#8733: I/O manager causes unnecessary syscalls in send/recv loops -------------------------------------+------------------------------------ Reporter: tibbe | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Description changed by tibbe: Old description:
Network applications often call send followed by recv, to send a message and then read an answer. This causes syscall traces like this one:
{{{ recvfrom(13, ) -- Haskell thread A sendto(13, ) -- Haskell thread A recvfrom(13, ) = -1 EAGAIN -- Haskell thread A epoll_ctl(3, ) -- Haskell thread A (a job for the IO manager) recvfrom(14, ) -- Haskell thread B sendto(14, ) -- Haskell thread B recvfrom(14, ) = -1 EAGAIN -- Haskell thread B epoll_ctl(3, ) -- Haskell thread B (a job for the IO manager) }}}
The recvfrom call always fails, as the response from the partner we're communicating with won't be available right after we send the request.
We ought to consider descheduling the thread as soon as sending is "done". The hard part is to figure out when that is.
See http://www.yesodweb.com/blog/2014/02/new-warp for a real world example.
New description: Network applications often call `send` followed by `recv`, to send a message and then read an answer. This causes syscall traces like this one: {{{ recvfrom(13, ) -- Haskell thread A sendto(13, ) -- Haskell thread A recvfrom(13, ) = -1 EAGAIN -- Haskell thread A epoll_ctl(3, ) -- Haskell thread A (a job for the IO manager) recvfrom(14, ) -- Haskell thread B sendto(14, ) -- Haskell thread B recvfrom(14, ) = -1 EAGAIN -- Haskell thread B epoll_ctl(3, ) -- Haskell thread B (a job for the IO manager) }}} The `recvfrom` call always fails, as the response from the partner we're communicating with won't be available right after we send the request. We ought to consider descheduling the thread as soon as sending is "done". The hard part is to figure out when that is. See http://www.yesodweb.com/blog/2014/02/new-warp for a real world example. -- -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8733#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#8733: I/O manager causes unnecessary syscalls in send/recv loops -------------------------------------+------------------------------------ Reporter: tibbe | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by carter): could it be done by having the end of the send call always yield? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8733#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#8733: I/O manager causes unnecessary syscalls in send/recv loops -------------------------------------+------------------------------------ Reporter: tibbe | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by tibbe): @carter it could, but then we might end up yielding before all the content has been sent (in case it's spread over several `send`s). We could think about having something similar to `TCP_CORK` to have the client communicate when it's ready to yield. On the other hand, if the client has to deal with this issue she might as well yield manually. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8733#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#8733: I/O manager causes unnecessary syscalls in send/recv loops -------------------------------------+------------------------------------ Reporter: tibbe | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by carter): yeah, you're right. In which case, might it make sense to have clear breadcrumbs for this technique in network or the like? eg (a strawman mind you) {{{ withYield :: IO a-> IO () withYield m = do m ; yield }}} this is probably the most wrong way possible, but I don't mean it as a serious suggestion. Merely that making yield more visible in the api surface might be a "social" approach to mitigate things. Eg, its always safe to add yields to code, but as you say, its not a good idea to just sprinkle it around. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8733#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#8733: I/O manager causes unnecessary syscalls in send/recv loops -------------------------------------+------------------------------------ Reporter: tibbe | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by etrepum): Is the IO manager the right layer to be approaching this from? Not all protocols are going to be strictly request/response with no pipelining or multiplexing like vanilla HTTP is. Why not implement this at a higher level in a library that encapsulates these best practices for various sorts of protocols? A good start may be to add this to the Performance Resource: http://www.haskell.org/haskellwiki/Performance (which looks old but that's what came up when I searched). Erlang publishes an Efficiency Guide that is nice (but doesn't cover any networking topics) http://erlang.org/doc/efficiency_guide/users_guide.html -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8733#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#8733: I/O manager causes unnecessary syscalls in send/recv loops -------------------------------------+------------------------------------ Reporter: tibbe | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by carter): yeah, that might be a good approach. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8733#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#8733: I/O manager causes unnecessary syscalls in send/recv loops --------------------------------------------+------------------------------ Reporter: tibbe | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by hvr): * cc: hvr (added) * failure: None/Unknown => Runtime performance bug * milestone: => 7.10.1 -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8733#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#8733: I/O manager causes unnecessary syscalls in send/recv loops --------------------------------------------+------------------------------ Reporter: tibbe | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by schyler): If I understand correctly, this can be implemented as a state machine. Each thread can have a "last IO action" state which gets reset when it yields and set to some constant on send/recv. Then, if you call recv and it's still in send mode, yield automatically (and yield would set it back to NULL). -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8733#comment:8 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
Is the IO manager the right layer to be approaching this from? Not all
#8733: I/O manager causes unnecessary syscalls in send/recv loops --------------------------------------------+------------------------------ Reporter: tibbe | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by tibbe): Replying to [comment:5 etrepum]: protocols are going to be strictly request/response with no pipelining or multiplexing like vanilla HTTP is.
Why not implement this at a higher level in a library that encapsulates
these best practices for various sorts of protocols? Good question. I considered this before filing the bug. One argument for why this should work without user interaction, in addition to the standard "it's nice if it just works" argument, is that if we didn't use the I/O manager but instead normal blocking syscalls, we'd end up with better behavior in this case.
A good start may be to add this to the Performance Resource: http://www.haskell.org/haskellwiki/Performance (which looks old but that's what came up when I searched). Erlang publishes an Efficiency Guide that is nice (but doesn't cover any networking topics) http://erlang.org/doc/efficiency_guide/users_guide.html
I'm planning to add a note to the network package's docs when I find the time. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8733#comment:9 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#8733: I/O manager causes unnecessary syscalls in send/recv loops --------------------------------------------+------------------------------ Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by simonmar): * owner: simonmar => Comment: Hmm. Isn't it application-specific knowledge that the recv() is going to block? I'm not sure what it is you're proposing that the IO manager should do, could you elaborate?
One argument for why this should work without user interaction, in addition to the standard "it's nice if it just works" argument, is that if we didn't use the I/O manager but instead normal blocking syscalls, we'd end up with better behavior in this case.
If you used blocking syscalls you'd end up with much worse scaling, that's why we have the IO manager, no? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8733#comment:10 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
If you used blocking syscalls you'd end up with much worse scaling,
#8733: I/O manager causes unnecessary syscalls in send/recv loops --------------------------------------------+------------------------------ Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by tibbe): Replying to [comment:10 simonmar]: that's why we have the IO manager, no? Sure. I guess I'm saying that the I/O manager makes some things better and some things worse. This bug is a bit nebulous. I'm not sure there's a good solution without involving the user. However, we should at least think about it as this will come up in more or less every server we write. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8733#comment:11 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#8733: I/O manager causes unnecessary syscalls in send/recv loops --------------------------------------------+------------------------------ Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by AndreasVoellmy): I would be interested to know what the source of the overhead is when making the recvfrom call that fails. I.e. is due to having more syscalls or from invoking the IO manager (Haskell-land) code to register the callback (requires taking an MVar, etc). If it is the sys call, then we would have to do something like you describe where you avoid making the recvfrom call right after the send. If, OTOH it is IO manager overhead, then we may be able to fix it by streamlining the IO manager. E.g. we could try to avoid taking any MVars to register callbacks. We've also talked about integrating the IO manager more closely with the threaded RTS and writing it in C. I think we could easily reduce the overhead if we go down that route. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8733#comment:12 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#8733: I/O manager causes unnecessary syscalls in send/recv loops --------------------------------------------+------------------------------ Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by AndreasVoellmy): * cc: andreas.voellmy@… (added) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8733#comment:13 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#8733: I/O manager causes unnecessary syscalls in send/recv loops --------------------------------------------+------------------------------ Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by tibbe): Replying to [comment:12 AndreasVoellmy]:
I would be interested to know what the source of the overhead is when making the recvfrom call that fails. I.e. is due to having more syscalls or from invoking the IO manager (Haskell-land) code to register the callback (requires taking an MVar, etc).
Good question. I have a theory that the `MVar` overheads might be hurting us and integrating the I/O manager with the scheduler could allow us to get around that. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8733#comment:14 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#8733: I/O manager causes unnecessary syscalls in send/recv loops --------------------------------------------+------------------------------ Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by hvr): Replying to [comment:14 tibbe]:
Good question. I have a theory that the `MVar` overheads might be hurting us and integrating the I/O manager with the scheduler could allow us to get around that.
Just wondering, would integration with the scheduler simplify implementing (soft) timeouts, like e.g. providing {{{#!hs threadWaitReadWithTimeout, threadWaitWriteWithTimeout :: Fd -> Int -> IO Bool }}} directly in the I/O manager? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8733#comment:15 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#8733: I/O manager causes unnecessary syscalls in send/recv loops --------------------------------------------+------------------------------ Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by AndreasVoellmy): When you say simplify, what are you comparing to? Is there some implementation of those functions that you are thinking of? Maybe you mean that those functions are implemented in a way similar to the`timeout :: Int -> IO a -> IO (Maybe a)` function in `System.Timeout`. I haven't measured the performance of `timeout` but I imagine it isn't very good, since it forks a new thread in each call. We do have a couple new functions in 7.8 that might allow us to provide a more efficient implementation than something like`timeout` . In 7.8, we have these functions: `threadWaitReadSTM :: Fd -> IO (STM (), IO ())` `threadWaitWriteSTM :: Fd -> IO (STM (), IO ())` They return an STM action that completes whenever the given file is ready to read (or write). Then we can use it in combination with `registerDelay :: Int -> IO (TVar Bool)` to wait on both the file and the timer without spawning a new thread. It would be something like this: {{{#!haskell threadWaitReadWithTimeout :: Fd -> Int -> IO Bool threadWaitReadWithTimeout fd n = do { (ready, _) <- threadWaitReadSTM fd; alarm <- registerDelay n; atomically ((ready >> return True)`orElse` (readTVar alarm >>= check >> return False)) } }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8733#comment:16 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#8733: I/O manager causes unnecessary syscalls in send/recv loops --------------------------------------------+------------------------------ Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by hvr): Replying to [comment:16 AndreasVoellmy]:
When you say simplify, what are you comparing to? Is there some implementation of those functions that you are thinking of?
Your suggestion of using the new `threadWait*STM` functions seems to be already an improvement over the naive `timeout`+`threadWait{Read,Write}` approach. I was originally thinking of a more low-level approach: Since `epoll`/`select` and similar OS sys-calls take a `timeout`-argument, that argument would be set according to the earliest due pending `threadWait*WithTimeout` calls when the need arises to actually call `epoll` to wait for new I/O events. Or does this implicitly happen anyway when using `registerDelay` which goes through the `TimeManager`? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8733#comment:17 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#8733: I/O manager causes unnecessary syscalls in send/recv loops --------------------------------------------+------------------------------ Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by AndreasVoellmy): The approach you mention is actually what the IO manager pre 7.8 did, although it didn't have `threadWait{Read,Write}WithTimeout` methods, so you would have to code this via the lower-level interface in `GHC.Event`. In the 7.8 IO manager, the approach you describe won't quite work. The 7.8 manager uses a separate `poll` instance to handle timeouts (much as you described) and uses `epoll` instances (one per HEC) to monitor files. The reason that we don't handle timeouts in the epoll instances anymore is that the 7.8 manager uses non-blocking calls to `epoll`, and it sometimes yields and moves to the back of the run queue of its HEC. This often reduces the number of blocking foreign calls. But it means that `epoll` may not be called in a timely fashion, because it may wait for a bunch of busy Haskell threads on its HEC to finish. For that reason, we keep a separate Haskell thread monitoring a `poll` instance just for timeouts. In contrast, in the pre-7.8 IO manager, the IO manager thread always did a blocking `epoll` call, so it could use the earliest timeout as the timeout for the `epoll` call. It would then have to wait for at most one Haskell thread to finish after the foreign `epoll` call returns in order to grab the HEC and dispatch callbacks. Tighter integration of the IO manager and the scheduler might help here. With the integration, we may not need the trick of sending the IO manager to the end of the run queue. Then we could probably match the latency characteristics of the pre-7.8 manager (wait at most one Haskell thread to fire callbacks) and the throughput of the 7.8 manager. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8733#comment:18 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
In contrast, in the pre-7.8 IO manager, the IO manager thread always did a blocking epoll call, so it could use the earliest timeout as the timeout for the epoll call. It would then have to wait for at most one Haskell
#8733: I/O manager causes unnecessary syscalls in send/recv loops --------------------------------------------+------------------------------ Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by tibbe): thread to finish after the foreign epoll call returns in order to grab the HEC and dispatch callbacks. We don't guarantee to wake the thread up exactly after N milliseconds, so unless the new I/O manager seriously delays wake-ups, I'd prefer it if we could skip having a completely separate timeout manager. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8733#comment:19 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#8733: I/O manager causes unnecessary syscalls in send/recv loops -------------------------------------+------------------------------------- Reporter: tibbe | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by maoe): * cc: maoe (added) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8733#comment:23 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#8733: I/O manager causes unnecessary syscalls in send/recv loops -------------------------------------+------------------------------------- Reporter: tibbe | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by lelf): * cc: lelf (added) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8733#comment:24 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
participants (1)
-
GHC