From: Kazimierz Krosman <k.krosman-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
To: Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org,
peter-WaGBZJeGNqdsbIuE7sb01tBPR1lH4CV8@public.gmane.org,
vvs-5HdwGun5lf+gSpxsJD1C4w@public.gmane.org,
corbet-T1hC0tSOHrs@public.gmane.org,
arnd-r2nGTMty4D4@public.gmane.org,
pmladek-AlSwsSmVLrQ@public.gmane.org,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org,
daniel-cYrQPVfZoowdnm+yROfE0A@public.gmane.org,
kay.sievers-tD+1rO4QERM@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
k.lewandowsk-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org,
m.niesluchow-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org,
richard.weinberger-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
b.zolnierkie-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org,
luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org,
knhoon.baik-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org
Subject: Re: [PATCH v6 0/8] Additional kmsg devices
Date: Fri, 26 Feb 2016 14:22:42 +0100 [thread overview]
Message-ID: <56D051A2.6050106@samsung.com> (raw)
In-Reply-To: <20160225214714.GJ6092-qYNAdHglDFBN0TnZuCh8vA@public.gmane.org>
On 02/25/2016 10:47 PM, Tejun Heo wrote:
> 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.
>> 2. Using kmsg can cause lower CPU utilisation in the real-word use case than
>> >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.
Could you explain in more detail what did you mean by IPC problems?
Thanks.
--
Kazimierz Krosman
Samsung R&D Institute Poland
Samsung Electronics
k.krosman-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org
next prev parent reply other threads:[~2016-02-26 13:22 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-24 11:53 [PATCH v6 0/8] Additional kmsg devices Kazimierz Krosman
[not found] ` <1456314801-32738-1-git-send-email-k.krosman-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
2016-02-24 11:53 ` [PATCH v6 1/8] printk: extract kmsg-related routines from printk.c to kmsg.c Kazimierz Krosman
2016-02-25 21:47 ` [PATCH v6 0/8] Additional kmsg devices Tejun Heo
[not found] ` <20160225214714.GJ6092-qYNAdHglDFBN0TnZuCh8vA@public.gmane.org>
2016-02-26 13:22 ` Kazimierz Krosman [this message]
2016-02-26 14:47 ` Petr Mladek
2016-02-27 11:54 ` Tejun Heo
2016-02-24 11:53 ` [PATCH v6 2/8] printk: add one function for storing log in proper format Kazimierz Krosman
2016-02-24 11:53 ` [PATCH v6 3/8] kmsg: introduce additional kmsg devices support Kazimierz Krosman
2016-02-26 14:05 ` Petr Mladek
2016-02-24 11:53 ` [PATCH v6 4/8] kmsg: add additional buffers support to memory class Kazimierz Krosman
2016-02-24 11:53 ` [PATCH v6 5/8] kmsg: add function for adding and deleting additional buffers Kazimierz Krosman
2016-02-24 11:53 ` [PATCH v6 6/8] kmsg: add ioctl for adding and deleting kmsg* devices Kazimierz Krosman
2016-02-24 11:53 ` [PATCH v6 7/8] kmsg: add ioctl for kmsg* devices operating on buffers Kazimierz Krosman
2016-02-24 11:53 ` [PATCH v6 8/8] kmsg: selftests Kazimierz Krosman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56D051A2.6050106@samsung.com \
--to=k.krosman-sze3o3uu22jbdgjk7y7tuq@public.gmane.org \
--cc=akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org \
--cc=arnd-r2nGTMty4D4@public.gmane.org \
--cc=b.zolnierkie-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org \
--cc=corbet-T1hC0tSOHrs@public.gmane.org \
--cc=daniel-cYrQPVfZoowdnm+yROfE0A@public.gmane.org \
--cc=gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org \
--cc=k.lewandowsk-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org \
--cc=kay.sievers-tD+1rO4QERM@public.gmane.org \
--cc=knhoon.baik-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org \
--cc=linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org \
--cc=m.niesluchow-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org \
--cc=peter-WaGBZJeGNqdsbIuE7sb01tBPR1lH4CV8@public.gmane.org \
--cc=pmladek-AlSwsSmVLrQ@public.gmane.org \
--cc=richard.weinberger-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=vvs-5HdwGun5lf+gSpxsJD1C4w@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).