Re: [PATCH v6 0/8] Additional kmsg devices

On Fri 2016-02-26 14:22:42, Kazimierz Krosman wrote:

On 02/25/2016 10:47 PM, Tejun Heo wrote:

quoted

I'm not sure this is the right layer to implement generic logging
facility.

In general this patches add only one feature- possibility of adding
and deleting
new kmsg devices, so I think that it can be treated as kmsg upgrade.

quoted

quoted

2. Using kmsg can cause lower CPU utilisation in the real-word use case than

quoted

userspace logging mechanisms.
We created 2 tests: (1) 100 writer processes write to created kmsg buffer and
(2) 100 writers write to socket (stream)- there is one reader to protect
socket buffer against overflow. Tests show that cpu utilisation in case of first
test is about 2.3 times lower (39.1%) than it is in second case (87.7%) (measured
with top program; tests code is attached below). Tested on Odroid XU4.

This sounds like a generic IPC problem than anything else.

For the test purpose I've written two tests (attached in cover
letter). I think that tests
show that in this use case (multiple writers) system with additional
kmsg devices
consumes less CPU time than system which use sockets for logging.
Logging system
based on sockets needs read process, that continuously reads socket
and protects
against socket buffers overflow and messages drop. It is one of
advantages of this
solution: no maintenance.

Wait. The net addition of this patch set is 1755 lines out of it
526 lines seems to be in non-test code. You added another level
of complexity into the handling of the ring buffer(s). And it will
require no maintenance?

Could you explain in more detail what did you mean by IPC problems?

I guess that the idea was to make IPC more effective in general.
You definitely could not move all functionality that needs IPC
into the kernel.

Best Regards,
Petr