Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752625AbbDUJgL (ORCPT ); Tue, 21 Apr 2015 05:36:11 -0400 Received: from 251.110.2.81.in-addr.arpa ([81.2.110.251]:50189 "EHLO lxorguk.ukuu.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752336AbbDUJgG (ORCPT ); Tue, 21 Apr 2015 05:36:06 -0400 Date: Tue, 21 Apr 2015 10:35:19 +0100 From: One Thousand Gnomes To: Andy Lutomirski Cc: Greg Kroah-Hartman , Richard Weinberger , David Herrmann , Linus Torvalds , Steven Rostedt , Jiri Kosina , Al Viro , Borislav Petkov , Andrew Morton , Arnd Bergmann , "Eric W. Biederman" , Tom Gundersen , "linux-kernel@vger.kernel.org" , Daniel Mack , Djalal Harouni Subject: Re: [GIT PULL] kdbus for 4.1-rc1 Message-ID: <20150421103519.5b0de5ea@lxorguk.ukuu.org.uk> In-Reply-To: References: <20150420205638.GA3015@kroah.com> <55356CC1.1040301@nod.at> <20150420214651.GA4215@kroah.com> Organization: Intel Corporation X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.27; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1730 Lines: 35 > 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/