[systemd-devel] [RFC 6/8] HACK2: blocking ioctl(CMD_MSG_RECV)

[AKASHI Takahiro]

Hi,

On 06/26/2014 12:39 PM, microcai wrote:
> 2014-06-25 18:30 GMT+08:00 Kay Sievers <kay at vrfy.org>:
>> On Wed, Jun 25, 2014 at 11:13 AM, AKASHI Takahiro
>> <takahiro.akashi at linaro.org> wrote:
>>> In the current implementation, ioctl(CMD_MSG_RECV) returns immediately if
>>> no message has been queued, and so a service process has to wait by
>>> explicitly calling poll() system call. If such a process needs to wait only
>>> on a single connection, we can eliminate poll() system call by adding a
>>> synchronous attribute in receiving a message.
>>
>> Why is this useful in general? The peer can call RECV in a loop until
>> EAGAIN without ever needing to call poll() as long as data is
>> available.
>>
>> When there is no more message to handle, poll() is used to suspend the
>> process, and only when it is idle anyway.

One of my ideas behind this hack is Binder's BINDER_WRITE_READ ioctl, which
is kinda combination of write(), poll() and read() in a single system call.
Obviously I don't want to implement such a function into KDbus, but apart from
Binder, "blocking until some messages arrive" is an commonly-seen attribute in
linux as well as other OSs.
One of well-known API's is recv() system call for socket interface.
If we don't have to wait on several end points, its the easiest way of programing
to catch incoming messages/data.

>> Busy processes, the use-case we would optimize for, should not see a
>> real benefit here?

So we can, at least, eliminate "one system call" overhead of poll().
I know that the improvement can be a bit smaller, on powerful processors,
than other hacks.

> And library can simulate the sync calls by revc + poll anyway.
> There is no real benefit.

Again, I'm not talking about functionality, but performance (or reducing overhead).

Thanks,
-Takahiro AKASHI