[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87tx1hxdgy.fsf@mid.deneb.enyo.de>
Date: Sun, 30 Nov 2014 10:08:29 +0100
From: Florian Weimer <fw@...eb.enyo.de>
To: Andy Lutomirski <luto@...capital.net>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Arnd Bergmann <arnd@...db.de>,
"Eric W. Biederman" <ebiederm@...ssion.com>,
One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>,
Tom Gundersen <teg@...m.no>, Jiri Kosina <jkosina@...e.cz>,
Linux API <linux-api@...r.kernel.org>,
"linux-kernel\@vger.kernel.org" <linux-kernel@...r.kernel.org>,
Daniel Mack <daniel@...que.org>,
David Herrmann <dh.herrmann@...il.com>,
Djalal Harouni <tixxdz@...ndz.org>
Subject: Re: kdbus: add documentation
* Andy Lutomirski:
> At the risk of opening a can of worms, wouldn't this be much more
> useful if you could share a pool between multiple connections?
They would also be useful to reduce context switches when receiving
data from all kinds of descriptors. At present, when polling, you
receive notification, and then you have to call into the kernel,
again, to actually fetch the data and associated information. The
kernel could also queue the data for one specific recipient,
addressing the same issue that SO_REUSEPORT tries to solve (on poll
notification, the kernel does not know which recipient will eventually
retrieve the data, so it has to notify and wake up all of them).
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists