Linus Is Looking Forward To Merging KDBUS, But Not Convinced By Performance

[newwen]

Great.... now would he mind kicking nfsd out of the kernel and back into userspace where it belongs?

nfsd was moved into the kernel for performance reasons.

[MartinN]

Phoronix: Linus Is Looking Forward To Merging KDBUS, But Not Convinced By Performance

With the new Linux kernel mailing list thread about the prospects of merging KDBUS into the mainline Linux kernel, Linus Torvalds has provided his thoughts on the matter for this controversial feature backed by systemd developers for trying to provide a high-performance, kernel-based IPC solution...

http://www.phoronix.com/scan.php?pag...Linus-Comments

Great! If it sucks as badly as Linus says, then make the dev rewrite the bloody thing and then allow it upstream. Who cares how long it takes? DBUS is already in place and can serve until KDBUS is good and ready.

[stoatwblr]

Great.... now would he mind kicking nfsd out of the kernel and back into userspace where it belongs?

[gens]

Endianness is a problem INSIDE a single machine?

endianness is not even a problem with networks
the protocol should just state if it's big or little endian in the definition and the machine can byte-swap itself if it needs

only place where its useful to define in a protocol is if the protocol will be used either between big endian or little endian machines, without much mixing
then again if the machine is running over... idk 10MHz then the overhead of byte swapping is negligible

none of this applies to dbus

PS i hate utf8 BOM

[TheBlackCat]

Endianness is a problem INSIDE a single machine? The only time you need to care about endianness is when you send data to/receive from a different machine that might have a different native endianness.

You may say that whoever designed that piece of crap was a visionary and thought of a time when the dbus protocol might be used to communicate between different machines, but then it's a lot more efficient to decide at compile time that you need to convert to big endian (x86 has the XCHG and BSWAP instructions exactly for this) instead of branching at run time over the first byte you received in the message.

So face it, the presence of that byte is a testament to the ignorance of the author on that endianness is and how it should be dealt with.

On a given machine, not all data has the same endianness. For example, all network data is big-endian, no matter what the native platform is. And some architectures natively support arbitrary endianness in a given piece of data.

So yeah, on x86, using local data, it doesn't matter. But on arm it matters no matter what, and even on x86 it matters if moving data from the network around.

[Ansla]

Endianess is a real problem when making a standard that works across multiple platforms and architectures like D-Bus does. What wasn't obvious at the time 10 years ago, was that you should just turn on one of the standards like "little" and let the "big" architectures performs an endianess swapping in their own implementation of the reference standard. In any case, this is just a minor cosmetic detail and doesn't make the protocol complex to neither understand nor use.

Endianness is a problem INSIDE a single machine? The only time you need to care about endianness is when you send data to/receive from a different machine that might have a different native endianness.

You may say that whoever designed that piece of crap was a visionary and thought of a time when the dbus protocol might be used to communicate between different machines, but then it's a lot more efficient to decide at compile time that you need to convert to big endian (x86 has the XCHG and BSWAP instructions exactly for this) instead of branching at run time over the first byte you received in the message.

So face it, the presence of that byte is a testament to the ignorance of the author on that endianness is and how it should be dealt with.

[gens]

No he didn't. It really pays well to read closely what Linus says, since he often is quite precise if indirect in his communication. What Linus said was that on the basis of what he had seen _yet_, he wasn't convinced about the speed argument.

This is Linus's way of saying the kdbus should deliver some real world benchmark examples. So if the kdbus developers are smart, they will do so. They have already made a improved D-Bus library (sd-bus) they can use for the test too.

PS. those "dumbasses" are Linux open source kernel developers, working for the Linux foundation or Linux distros. What exactly are your credentials for calling them names? If you think name calling is a substitute for technical arguments, then you are wrong.

they do not work for the linux foundation
and Linus did benchmark the thing, properly
unlike the devs that claim it brings 1000x speedup, that didn't benchmark it properly
actually the only other benchmark was by a person not even closely related to any of this

compared to something like the latest scheduler, that has a scientific paper with micro and real world benchmarks
it showed and explained where the new scheduler will be better and worse then the mainline one, objectively with numbers

if the kdbus devs were smart they would note that the overhead of dbus as used today is not even above margin of error
and they would have left it alone
maybe improved the server part and especially the glib part


and no, dbus is complicated
that what i showed is just a client sending a msg to a server
the server does a lot more
its 13k lines of code, for gods sake

[interested]

The large data argument has already been debunked. Torvalds said plainly, if it was just for that, then there's no chance it would get merged. Shitty userspace code is not a reason to put junk in the kernel. Besides as soon as dumbasses start putting data on it, it's gonna backfire hard right into their faces.

No he didn't. It really pays well to read closely what Linus says, since he often is quite precise if indirect in his communication. What Linus said was that on the basis of what he had seen _yet_, he wasn't convinced about the speed argument.

This is Linus's way of saying the kdbus should deliver some real world benchmark examples. So if the kdbus developers are smart, they will do so. They have already made a improved D-Bus library (sd-bus) they can use for the test too.

PS. those "dumbasses" are Linux open source kernel developers, working for the Linux foundation or Linux distros. What exactly are your credentials for calling them names? If you think name calling is a substitute for technical arguments, then you are wrong.

[duby229]

The large data argument has already been debunked. Torvalds said plainly, if it was just for that, then there's no chance it would get merged. Shitty userspace code is not a reason to put junk in the kernel. Besides as soon as dumbasses start putting data on it, it's gonna backfire hard right into their faces.

[interested]

http://dbus.freedesktop.org/doc/dbus-specification.html#message-protocol

the protocols first byte is an endianness flag
-it deals with endianness, that no sane protocol should

Endianess is a real problem when making a standard that works across multiple platforms and architectures like D-Bus does. What wasn't obvious at the time 10 years ago, was that you should just turn on one of the standards like "little" and let the "big" architectures performs an endianess swapping in their own implementation of the reference standard. In any case, this is just a minor cosmetic detail and doesn't make the protocol complex to neither understand nor use.

-the "flag" is one byte, instead of 1 bit
2nd byte is msg type, theres 3 (plus error and "unknown")
3rd byte is an OR of 3 flags
4th is the protocol version (mind you this goes in every msg)
then there are 2 32bit paramaters, data length and a cookie
and still no data, data comes after additional paramater fields that depend on msg type and flags

that's just a basic msg format, the protocol defines a lot more things
maybe you are thinking about the API

Really, the D-Bus protocol isn't hairy or complex. It isn't simple either, but neither is the problem it solves.

and no, i never said you should reinvent broadcasting
i specifically said that dbus should not be used for latency or throughput sensitive problems
for example; using dbus to discover/connect to a media player is fine, while using dbus to actually transport the media is not

The point is exactly that D-Bus as it is now doesn't work well with large data transfers. That is one major reason both desktop and daemon developers wants kdbus, since running the D-Bus protocol on top of the kdbus shared bus makes such data intensive transfers both fast _and_ secure.

And yes, you really want to use all the communication and security framework features that kdbus/D-Bus provides for the data too.


The bottom line is, that if you want to solve the same problems as kdbus/D-Bus does, you will end up reinventing both, the difference being that this alternative solution would have zero deployment in user space, unlike D-Bus that is widely supported in both daemons, desktops and init systems. You would basically have to re-write the world instead of re-using what is at hand. An insane trade-off.

Sure, you could let D-Bus run atop of a more generic kernel IPC than kdbus. But such a generic IPC for Linux have been a pipe dream for 25 years. As it is now, nobody even have any serious plans for such a generic IPC, nor the funding, nor the backing from user land.