> On top of that, I think that someone into resource management needs to > seriously consider whether having a broadcast send do get_user_pages > or the equivalent on pages supplied by untrusted recipients (plural!) > is a good idea.
Oh but its so much fun if you pass pages belonging to a device driver, or pass bits of a GEM object thereby keeping entire graphics textures referenced 8) The get_user_pages stuff looks like simple case of premature optimisation (or I suspect pessmimisation). If bulk data goes via memfd/splice/socket point to point as it should (or via shared memory objects) then you don't need all the page pinning and that begins to simplify the code a lot. Copies of small messages are cheap if not free on most processors. Its a memcpy into a simple refcounted buffer which gets deleted when the refcount hits zero. (I'd argue for also looking at stuff like GEM and the dma buffers for some of the big stuff. As we move towards more and more accelerators again being able to pass around handles between accelerator more and more important) We do need something for the multicast messaging. Whether that's supporting AF_LOCAL, SOCK_RDP with multicast or something else (POSIX message queue extensions ?). There's no real IP layer reliable ordered multicast delivery system that is low latency and lightweight because once it hits real networks it changes from a hard problem into a seriously hard problem because of multicast implosions and the like. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
