[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160225214714.GJ6092@mtj.duckdns.org>
Date: Thu, 25 Feb 2016 16:47:14 -0500
From: Tejun Heo <tj@...nel.org>
To: Kazimierz Krosman <k.krosman@...sung.com>
Cc: akpm@...ux-foundation.org, peter@...leysoftware.com,
vvs@...tuozzo.com, corbet@....net, arnd@...db.de, pmladek@...e.cz,
gregkh@...uxfoundation.org, daniel@...que.org,
kay.sievers@...y.org, linux-kernel@...r.kernel.org,
linux-doc@...r.kernel.org, linux-api@...r.kernel.org,
k.lewandowsk@...sung.com, m.niesluchow@...sung.com,
richard.weinberger@...il.com, b.zolnierkie@...sung.com,
luto@...capital.net, knhoon.baik@...sung.com
Subject: Re: [PATCH v6 0/8] Additional kmsg devices
Hello, Kazimierz.
On Wed, Feb 24, 2016 at 12:53:13PM +0100, Kazimierz Krosman wrote:
> 1. kmsg device does not require maintenance by reader process side.
> Multiple writers can write to a device and new records overwrite logs saved earlier.
> When system crashes logs can be restored with pstore mechanism.
I'm not sure this is the right layer to implement generic logging
facility.
> 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.
Thanks.
--
tejun
Powered by blists - more mailing lists