957828 - Reduce the number of copies involved in sending IPC Messages

Status: RESOLVED FIXED

(Core :: IPC, defect)

Description

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

bent noticed that we make a copy of every IPC message before we send it.[0]  That's going to be terrible for the performance and memory usage of anything that does heavy IPC traffic, and could lead to OOM of things like the Twitter app.

[0] http://hg.mozilla.org/mozilla-central/annotate/f99c42bb080e/ipc/glue/MessageChannel.cpp#l248

Comment 1

[Nicholas Nethercote [inactive]]

I wonder if bug 957498 has the same root cause.

Comment 2

[Thinker Li [:sinker]]

I think we should aim on big memory chunks, for example, big strings and memory blocks.  For small data, copying is not really serious.  I had look into the problem of big memory chunks of IPC, and found we could use shared memory to avoid copying.  But, it is not easy to manage life cycle of memory map, and you would mmap the memory correctly at first moment.  But, for most situations, you don' know the buffer would be used for IPC.  For example, sending content of JS strings through IPC.  So, start to write a kernel module to implement shared memory with COW. (see the following link.)  You could assigned a range as shared memory, then the module would return a fd.  Then, the fd could be sent to the peer of an IPC channel.  The peer process could mmap the fd to its memory space, so two processes shared the same list of pages.  But, any changes to the pages would trigger a copying for COW.


This approach requires an additional kernel module, but more easy to use and apply.

https://bitbucket.org/thinker/memcow

Comment 3

[Thinker Li [:sinker]]

I had described something wrong.  The peer process does not mmap the fd, it calls ioctl() to map pages into a block of anonymous pages.  So, the app code don't need to manage memory map.

Comment 4

[Ben Turner (not reading bugmail, use the needinfo flag!)]

Attachment: Stop copying messages for simple stack accounting, v1

Avoids the copy for our stack tracking. We currently only need a few things from the message, not the entire payload.

Comment 5

[Ben Turner (not reading bugmail, use the needinfo flag!)]

Attachment: Move the stack tracking classes to the cpp, v1

This is just a mechanical change to move the stack classes to the cpp to cut down on the rebuilds needed for changes to these classes.

Comment 6

[Ben Turner (not reading bugmail, use the needinfo flag!)]

(In reply to Thinker Li [:sinker] from comment #2)
Yeah, this bug isn't so much about copying between processes, just copying unnecessarily on the stack.

Comment 7

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

Hi ben,

I am guessing that this bug may provide us solution for https://bugzilla.mozilla.org/show_bug.cgi?id=956105 . I tried to apply both of your patches . But It gives some conflicts . Could you please rebase your patches again :)

Comment 8

[Ben Turner (not reading bugmail, use the needinfo flag!)]

Attachment: Rollup patch for 28 branch

Here's one for gecko 28 that includes both of the trunk patches. I didn't see any conflicts applying the others though...

Comment 9

[Ben Turner (not reading bugmail, use the needinfo flag!)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/781816c1eefd
https://hg.mozilla.org/integration/mozilla-inbound/rev/356ce17c2c45

Comment 10

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/781816c1eefd
https://hg.mozilla.org/mozilla-central/rev/356ce17c2c45

Comment 12

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/3e215a0da780