Consider batching some IPC messages to be sent together
Categories
(Core :: IPC, enhancement)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox110 | --- | fixed |
People
(Reporter: nika, Assigned: nika)
References
Details
Attachments
(3 files)
(note: This is a very experimental idea. It might turn out the approach isn't workable, or doesn't have any noticeable performance/power usage benefits)
In gecko, we have a number of IPC messages which are sent to update some data in another process so that it's available for future IPC. For example, the PContent::InsertNewFocusActionId message is sent to the parent process to tell it to record an focus action ID so it's available when a future IPC message to the parent also names the ID. This ends up being quite inefficient, as we end up sending a ton of IPC within focus handling code, generally slowing it down, even when we don't need to send a message to the parent process immediately.
This bug is to investigate an idea for improving the efficiency of these "lazy" IPC messages. The idea is that the messages would be marked as such in the IPDL layer, and when sending a lazy IPC message, it won't immediately be sent. Instead, the message will be queued up in the MessageChannel, and sent either immediately before a non-lazy IPC message is sent (to maintain message ordering invariants), or at some future point in time (e.g. at the end of the current task using direct dispatch, or on an idle timer), in order to avoid waiting forever.
The hope is that by sending the messages closer together, we can reduce the number of times we wake-up background threads, such as the processes' I/O threads and the receiving thread, improving power use and potentially also performance.
This is a very mild form of batching, as the messages would still be being sent using individual system calls, and separate runnables would still be dispatched for each message, but it should hopefully be safe enough to not break ordering invariants.
|
Assignee | |
Comment 1•2 years ago
|
||
I've done some initial testing with this, and the results are looking promising. It seems like it's improving Windows 10 Speedometer performance by ~3-4% (perfherder). The specific improvements seem to largely come from the Inferno subtest, which dropped by ~40%. This is likely due to the reduced inline bottleneck of sending the small IPC messages in the Inferno benchmark which was shown to be an issue with bug 1794282 - though the improvements may have been inflated due to bug 1803500.
There appears to be little to no benefit on non-windows platforms, which makes sense given the differences in worker thread IPC sending overhead and small message worker thread wakeup overhead.
|
|
Assignee | |
Comment 2•2 years ago
|
||
This is intended to be used to mark messages which do nothing on the
receiving side other than setting up state for future IPC messages,
meaning that the send can be delayed until other more important work is
complete, or until a non-LazySend IPC message is sent.
This does not break any message ordering guarantees, as the lazy
messages will be sent in order before any non-lazy messages are sent.
|
|
Assignee | |
Comment 3•2 years ago
|
||
Depends on D164274
|
|
Assignee | |
Comment 4•2 years ago
|
||
See part 1 for an explanation of the attribute. To my approximation,
these messages appear to be ones which should be OK to delay sending
until another message is sent, or an idle runnable is fired, as they
largely set up state in the receiving process for future messages.
I tried not to be too aggressive at least at first, and this attribute
is fairly safe, so it is possible that we could get some benefits from
many more messages being annotated with it in the future.
The riskiest messages which were annotated are probably the
Commit{Browsing,Window}ContextTransaction messages as they have very
broad responsibilities and potential effects. It seemed like it would be
valuable to mark them as [LazySend] however, as they are one of the most
frequent messages and generally are supposed to just be updating synched
members on BrowsingContext instances.
Depends on D164275
|
||
Updated•2 years ago
|
|
||
Comment 6•2 years ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/99728966262d
https://hg.mozilla.org/mozilla-central/rev/15bb8a9d0965
https://hg.mozilla.org/mozilla-central/rev/c5868e87321e
|
||
Comment 7•2 years ago
|
||
Appears to improve the following on Speedometer2:
Inferno-TodoMVC/CompletingAllItems
Inferno-TodoMVC/CompletingAllItems/Sync
Inferno-TodoMVC/DeletingItems
Inferno-TodoMVC/DeletingItems/Sync
And regress the following:
Inferno-TodoMVC/CompletingAllItems/Async
Inferno-TodoMVC/DeletingItems/Async
So looks like the Sync version of tests improve, while the Async version of the tests regress.
Description
•