From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932276AbcBZNXA (ORCPT ); Fri, 26 Feb 2016 08:23:00 -0500 Received: from mailout3.w1.samsung.com ([210.118.77.13]:14146 "EHLO mailout3.w1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751505AbcBZNW6 (ORCPT ); Fri, 26 Feb 2016 08:22:58 -0500 X-AuditID: cbfec7f4-f79026d00000418a-98-56d051afb95d Subject: Re: [PATCH v6 0/8] Additional kmsg devices To: Tejun Heo References: <1456314801-32738-1-git-send-email-k.krosman@samsung.com> <20160225214714.GJ6092@mtj.duckdns.org> Cc: akpm@linux-foundation.org, peter@hurleysoftware.com, vvs@virtuozzo.com, corbet@lwn.net, arnd@arndb.de, pmladek@suse.cz, gregkh@linuxfoundation.org, daniel@zonque.org, kay.sievers@vrfy.org, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-api@vger.kernel.org, k.lewandowsk@samsung.com, m.niesluchow@samsung.com, richard.weinberger@gmail.com, b.zolnierkie@samsung.com, luto@amacapital.net, knhoon.baik@samsung.com From: Kazimierz Krosman Message-id: <56D051A2.6050106@samsung.com> Date: Fri, 26 Feb 2016 14:22:42 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-version: 1.0 In-reply-to: <20160225214714.GJ6092@mtj.duckdns.org> Content-type: text/plain; charset=windows-1252; format=flowed Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrBIsWRmVeSWpSXmKPExsVy+t/xq7rrAy+EGVxfxmwxZ/0aNou/k46x W2ycsZ7V4smBdkaLpr+vWCyaF69ns7jwPMCi8dNcZovLG86xWax4cZjRYvP3DjaLhW1LWCwu 75rDZrF6bQOrxaGzP1gsjl36x2ix8P9mJosPEzewWfxafpTR4uCyWWwOIh733/xl8fj9axKj x85Zd9k9VvxZz+axaVUnm8eJGb9ZPPbPXcPusbhvMqtH35ZVjB5nFhxh9/i8Sc7j9f5DjB4f 13t6bN+9nCWAL4rLJiU1J7MstUjfLoEr41RzXsEH7opZm84yNzAe5Oxi5OSQEDCR2PTrOzOE LSZx4d56ti5GLg4hgaWMEu8fPGOGcJ4xSjxcd40RpEpYwFhi9eHLLCC2iICsxJVpD8HiQgL5 Eo1Pp4E1MAvsZJa4+u8SO0iCTUBf4vy5KUwgNq+AlkR/+2ZWEJtFQFVibvdSsLioQITEqbNv 2SBqBCV+TL4HtoAT6LzPTffBapgFbCUWvF/HAmHLS2xe85Z5AqPALCQts5CUzUJStoCReRWj aGppckFxUnquoV5xYm5xaV66XnJ+7iZGSPx+2cG4+JjVIUYBDkYlHl6JC+fDhFgTy4orcw8x SnAwK4nwztW+ECbEm5JYWZValB9fVJqTWnyIUZqDRUmcd+6u9yFCAumJJanZqakFqUUwWSYO TqkGxjV/D0z8b/E/JORJ70ltyYmHY17e4JwRfZBhpaNGaW6wk4OjY11V2+cJ3hdmzE9n0V09 +/LtjTyK+2KeFvyZFfZ3ShlD84ql83/uYDI8yte0t3dd7HWVzdJdZe72vG2P9x691f+09fir nwbyM21TE/5mqdrWnshWKVl9QPKaVtAOkbNpAj+V1JVYijMSDbWYi4oTAbm11uXbAgAA Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.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@samsung.com