[systemd-devel] [RFC] [PATCH 0/3] journal: Add deferred log processing to reduce synchonous IO overhead

[Lennart Poettering]

On Fri, 13.12.13 12:46, Karol Lewandowski (k.lewandowsk at samsung.com) wrote:

> >> From 2.6.29 it's in mailine kernel under
> >> drivers/staging/android/logger.c
> > 
> > But if the the socket layer is really thaaaaat much slower than android
> > logging, then that's kinda sad, and the kernel socket stuff should
> > probably be fixed?
> 
> It's not that slower when we take throughput as only parameter:
> 
> packet   |              |
> size [B] | Adnroid [kB] |  DGRAM [kB]
> ---------+--------------+------------
>   64     |    110640    |     84827
>  128     |    212602    |    166866
>  256     |    423880    |    328440
>  512     |    815094    |    644499
> 1024     |   1543326    |   1246914
> 2048     |   2751674    |   2359654
> 4096     |   2821260    |   4145395
> 
> However, if take context switches into account picture starts
> to look differently:
> 
>                  | Android   |   DGRAM
> -----------------+-----------+--------------
> context switches |  1818     |   580443      (involuntary + voluntary)
>                  |           |
> system time      | 149.97    |   118.62      [seconds]
> user time        |   4.03    |     7.45      [secodns]
> 
> (Columns contain cumulative data: client  + server)
> 
> Attached raw results and test program.

Well, are you suggesting that the AF_UNIX/SOCK_DGRAM code actually hands
off the timeslice to the other side as soon as it queued something in?
THat would be news to me. The kernel does context switches when the
timeslice is over not earlier afaik, and you'll get that aynway...

> >>>> This is why I decided to try to make logging completely async and see
> >>>> if/what changes.
> >>>
> >>> Well, if AF_UNIX is slow, then we really should try to fix that in the
> >>> kernel instead of bypassing it in userspace... Whether we rely on the
> >>> socket buffer of the AF_UNIX socket or put together our own buffer in
> >>> /dev/shm shouldn't be much of a difference if they both have the same
> >>> size and can take the same number of entries...
> >>
> >> I do agree.  Truth is I have looked at linux/net/ code once but I
> >> didn't grok it well.  I guess it's the time to take a second look. ;)
> > 
> > Here's another option: extend journald to use kdbus as additional
> > transport. This is something we want to do anyway since the kdbus
> > transport will attach the metadata we need without race to each
> > packet. Given that kdbus ultimately is just a way to write into an
> > mmaped tmpfs that some other process owns this should not be much worse
> > than the android logger in performance.
> 
> I doubt it would help as other side would still be woken up on _every_
> message, right?

Well, it gets woken up if its waiting for that. But the kernel will only
give CPU time to it when the senders timeslice is over... There's very
little difference to mmap... I mean, you need to tell the other side
that it should look in the buffer, how do you want to do that otherwise?

Lennart

-- 
Lennart Poettering, Red Hat