Re: dbus moving into kernel?
Il giorno sab, 25/09/2010 alle 19.57 +0400, Gennady Kupava ha scritto: В Птн, 24/09/2010 в 15:11 +0200, Marco Trevisan (Treviño) пишет: Some days ago I've tried to port this patch to the Openmoko kernel, after applying it to the SHR 2.6.32 kernel (patches at [1]), I got these results (in average): dbus-ping-pong test: Pingdbus-daemon (s) kdbus (s) speedup 500 ping3.332.1336.2% 5000 ping 32.59 26.09 19.9% 5 ping 313.56 176.35 43.8% Adrien Bustany’s ipc-performances tool with 6 random 10 char strings: dbus-daemon query (s) kdbus query (s) speedup 102.75 74.71 27.29% Interesting, how adding FCSE will influence this dbus test? I've tried FCSE too, but I can't get a working kernel after patching... I should retest. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: dbus moving into kernel?
Marco Trevisan (Treviño) m...@3v1n0.net writes: Il giorno gio, 16/09/2010 alle 17.23 +0100, Al Johnson ha scritto: kdbus is proof-of-concept at the moment, the idea being to reduce the number of context switches needed for each dbus message. One synthetic benchmark shows a 3x speed increase on the n900 but speedup in real world applications seems much more modest. http://alban.apinc.org/blog/2010/09/15/d-bus-in-the-kernel-faster/ Some days ago I've tried to port this patch to the Openmoko kernel, after applying it to the SHR 2.6.32 kernel (patches at [1]), I got these results (in average): dbus-ping-pong test: Ping dbus-daemon (s) kdbus (s) speedup 500 ping 3.332.1336.2% 5000 ping 32.59 26.09 19.9% 5 ping313.56 176.35 43.8% Adrien Bustany’s ipc-performances tool with 6 random 10 char strings: dbus-daemon query (s) kdbus query (s) speedup 102.7574.71 27.29% So, the results are quite good, but the code is actually buggy... [...] I guess that this system could give us a nice speedup when with many core applications with very few sources changes. Comments? Looking at your numbers, we're talking about shaving `up to 43.8%' off of something that's already down in the singe-digit milliseconds range to start with: in the best case above, it goes from 6.3 ms per query to 3.5 ms per query; in the worse cases, it goes from 6.5 ms down to 5.2 ms. In your last test with Adrien's tool, the 27.29% improvement is from 1.7 ms to 1.2 ms. Is D-Bus actually enough of a bottleneck in, say, the FSO or SHR designs that we should expect to accumulate enough of these ~2-ms reductions quickly enough for them to actually become noticeable? An improvement of `2 ms per' can be worthwhile if it adds up quickly enough--but does it? How long does it take, under normal operating conditions, before even 50 D-Bus calls are made (a total of 0.1 seconds of accumulated savings)? I don't know the answers to these questions, so they're not rhetorical :) -- Don't be afraid to ask (λf.((λx.xx) (λr.f(rr. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: dbus moving into kernel?
Looking at your numbers, we're talking about shaving `up to 43.8%' off of something that's already down in the singe-digit milliseconds range to start with: in the best case above, it goes from 6.3 ms per query to 3.5 ms per query; in the worse cases, it goes from 6.5 ms down to 5.2 ms. In your last test with Adrien's tool, the 27.29% improvement is from 1.7 ms to 1.2 ms. waah? dbus in kernel space? well we could really try to make the system-bus more system ;-) Is D-Bus actually enough of a bottleneck in, say, the FSO or SHR designs that we should expect to accumulate enough of these ~2-ms reductions quickly enough for them to actually become noticeable? An improvement of `2 ms per' can be worthwhile if it adds up quickly enough--but does it? How long does it take, under normal operating conditions, before even 50 D-Bus calls are made (a total of 0.1 seconds of accumulated savings)? Hmm. Well, its really something making the system slower. But would the change to kdbus really make SHR/FSO that faster? ... but its worth a try... I don't know the answers to these questions, so they're not rhetorical :) There are empiric facts needed... Indeed regards leviathan signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: dbus moving into kernel?
В Птн, 24/09/2010 в 15:11 +0200, Marco Trevisan (Treviño) пишет: Some days ago I've tried to port this patch to the Openmoko kernel, after applying it to the SHR 2.6.32 kernel (patches at [1]), I got these results (in average): dbus-ping-pong test: Ping dbus-daemon (s) kdbus (s) speedup 500 ping 3.332.1336.2% 5000 ping 32.59 26.09 19.9% 5 ping313.56 176.35 43.8% Adrien Bustany’s ipc-performances tool with 6 random 10 char strings: dbus-daemon query (s) kdbus query (s) speedup 102.7574.71 27.29% Interesting, how adding FCSE will influence this dbus test? Gennady. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: dbus moving into kernel?
Il giorno gio, 16/09/2010 alle 17.23 +0100, Al Johnson ha scritto: kdbus is proof-of-concept at the moment, the idea being to reduce the number of context switches needed for each dbus message. One synthetic benchmark shows a 3x speed increase on the n900 but speedup in real world applications seems much more modest. http://alban.apinc.org/blog/2010/09/15/d-bus-in-the-kernel-faster/ Some days ago I've tried to port this patch to the Openmoko kernel, after applying it to the SHR 2.6.32 kernel (patches at [1]), I got these results (in average): dbus-ping-pong test: Pingdbus-daemon (s) kdbus (s) speedup 500 ping3.332.1336.2% 5000 ping 32.59 26.09 19.9% 5 ping 313.56 176.35 43.8% Adrien Bustany’s ipc-performances tool with 6 random 10 char strings: dbus-daemon query (s) kdbus query (s) speedup 102.75 74.71 27.29% So, the results are quite good, but the code is actually buggy... In fact when enabling it for the system dbus session (which our FSO-based phone mostly uses for exchanging data between apps), some applications doesn't work as expected (Messages, Contacts...), since the kdbus socket actually just supports only dbus requests with few parameters ( 8kB) and these apps really have greater requests... By the way, waiting for kdbus upstream fixes (I've already contacted its author, who is now aware of the bugs I found), I guess that this system could give us a nice speedup when with many core applications with very few sources changes. Comments? PS: More informations about my issues have been filled as comments of of the alban's blog article linked above. [1] http://pastebin.com/3kfnUqzb ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: dbus moving into kernel?
Patryk Benderz wrote: Dnia 2010-09-16, czw o godzinie 17:23 +0100, Al Johnson pisze: kdbus is proof-of-concept at the moment, the idea being to reduce the number of context switches needed for each dbus message. One synthetic benchmark shows a 3x speed increase on the n900 but speedup in real world applications seems much more modest. There are a lot of complaints about Dbus IPC. That makes me wonder why people don't use one of already existing kernel IPCs [1][2] , and instead try to develop another one, which is not secure as I heard? [1] http://tldp.org/LDP/lpg/node7.html [2] http://tldp.org/LDP/tlk/ipc/ipc.html Actually, netlink comes to mind as a transport layer for something like dbus. It can not all that dbus can, but most of those so called features are actually a total wank anyway. At least it would scale. But I suppose this discussion was lost when dbus was new and it is pointless these days. Dbus will probably have a successor some day, and with any luck it will have more sane foundations... Actually, dbus is not that bad. Some of the things it can do require a approach like they took. Question is, should we have sacrificed those features on the alter of simplicity? I'm not even sure I have a answer to that... Regards Tilman Baumann ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: dbus moving into kernel?
Dnia 2010-09-20, pon o godzinie 11:32 +0100, Tilman Baumann pisze: Patryk Benderz wrote: Dnia 2010-09-16, czw o godzinie 17:23 +0100, Al Johnson pisze: kdbus is proof-of-concept at the moment, the idea being to reduce the number of context switches needed for each dbus message. One synthetic benchmark shows a 3x speed increase on the n900 but speedup in real world applications seems much more modest. There are a lot of complaints about Dbus IPC. That makes me wonder why people don't use one of already existing kernel IPCs [1][2] , and instead try to develop another one, which is not secure as I heard? [1] http://tldp.org/LDP/lpg/node7.html [2] http://tldp.org/LDP/tlk/ipc/ipc.html Actually, netlink comes to mind as a transport layer for something like dbus. It can not all that dbus can, but most of those so called features are actually a total wank anyway. At least it would scale. But I suppose this discussion was lost when dbus was new and it is pointless these days. Dbus will probably have a successor some day, and with any luck it will have more sane foundations... Actually, dbus is not that bad. Some of the things it can do require a approach like they took. Question is, should we have sacrificed those features on the alter of simplicity? I'm not even sure I have a answer to that... Nor do I. However I suppose Dbus should have been designed and built conforming to Unix Philosophy [1], and it seems it was not. [1] http://en.wikipedia.org/wiki/Unix_philosophy -- Patryk LeadMan Benderz Linux Registered User #377521 () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: dbus moving into kernel?
Dnia 2010-09-16, czw o godzinie 17:23 +0100, Al Johnson pisze: kdbus is proof-of-concept at the moment, the idea being to reduce the number of context switches needed for each dbus message. One synthetic benchmark shows a 3x speed increase on the n900 but speedup in real world applications seems much more modest. There are a lot of complaints about Dbus IPC. That makes me wonder why people don't use one of already existing kernel IPCs [1][2] , and instead try to develop another one, which is not secure as I heard? [1] http://tldp.org/LDP/lpg/node7.html [2] http://tldp.org/LDP/tlk/ipc/ipc.html -- Patryk LeadMan Benderz Linux Registered User #377521 () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments Email secured by Check Point ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: dbus moving into kernel?
Patryk Benderz patryk.bend...@esp.pl writes: Dnia 2010-09-16, czw o godzinie 17:23 +0100, Al Johnson pisze: kdbus is proof-of-concept at the moment, the idea being to reduce the number of context switches needed for each dbus message. One synthetic benchmark shows a 3x speed increase on the n900 but speedup in real world applications seems much more modest. There are a lot of complaints about Dbus IPC. That makes me wonder why people don't use one of already existing kernel IPCs [1][2] , and instead try to develop another one, which is not secure as I heard? [1] http://tldp.org/LDP/lpg/node7.html [2] http://tldp.org/LDP/tlk/ipc/ipc.html I once heard a conversation between two of my fellow engineers: e0: I think it's time we came up with something like an API. e1: We have an API. e0 (joking): What, `PEEK and POKE'? e1 (seriously): Yes--`PEEK and POKE' *is* an API. (neither e0 nor I work there, anymore--but I hear that e1 got promoted) Of course people *do* use pipes and sockets, etc.: those are the primitives on which something more fully-featured (like RPC, or CORBA, or D-Bus) is built. -- Don't be afraid to ask (λf.((λx.xx) (λr.f(rr. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
dbus moving into kernel?
kdbus is proof-of-concept at the moment, the idea being to reduce the number of context switches needed for each dbus message. One synthetic benchmark shows a 3x speed increase on the n900 but speedup in real world applications seems much more modest. http://alban.apinc.org/blog/2010/09/15/d-bus-in-the-kernel-faster/ ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: dbus moving into kernel?
В Чтв, 16/09/2010 в 17:23 +0100, Al Johnson пишет: kdbus is proof-of-concept at the moment, the idea being to reduce the number of context switches needed for each dbus message. One synthetic benchmark shows a 3x speed increase on the n900 but speedup in real world applications seems much more modest. http://alban.apinc.org/blog/2010/09/15/d-bus-in-the-kernel-faster/ Oh, no! Linux kernel with analogue of windows messaging subsystem, but implemented in slower way... why not use Windows instead? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
