Message-id: <559CDF8B.2090000@samsung.com>
Date:	Wed, 08 Jul 2015 10:30:03 +0200
From:	Marcin Niesluchowski <m.niesluchow@...sung.com>
To:	Richard Weinberger <richard@....at>
Cc:	"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>,
	"open list:ABI/API" <linux-api@...r.kernel.org>,
	Jonathan Corbet <corbet@....net>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Petr Mladek <pmladek@...e.cz>, Tejun Heo <tj@...nel.org>,
	Kay Sievers <kay@...y.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Joe Perches <joe@...ches.com>,
	Karol Lewandowski <k.lewandowsk@...sung.com>,
	Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>
Subject: Re: [RFC 0/8] Additional kmsg devices

On 07/03/2015 05:19 PM, Richard Weinberger wrote:
> Am 03.07.2015 um 17:09 schrieb Marcin Niesluchowski:
>>> Why can't you just make sure that your target has a working
>>> syslogd/rsyslogd/journald/whatever?
>>> All can be done perfectly fine in userspace.
>> * Message credibility: Lets imagine simple service which collects logs via unix sockets. There is no reliable way of identifying logging process. getsockopt() with SO_PEERCRED
>> option would give pid form cred structure, but according to manual it may not be of actual logging process:
>>    "The returned credentials are those that were in effect at the time of the call to connect(2) or socketpair(2)."
>>        - select(7)
> This interface can be improved. Should be easy.

What kind of improvement do you have in mind?

>> * Early userspace tool: Helpful especially for embeded systems.
> This is what we do already. In early user space spawn your logger as early as possible.
> "embedded Linux is special" is not an excuse btw. ;)

I would say "embedded Linux is real use case"instead of "special". What 
I meant that it does only require one ioctl and no additional resources 
are needed.

>> * Reliability: Userspace service may be killed due to out of memory (OOM). This is kernel cyclic buffer, which size can be specified differently according to situation.
> This is what we have /proc/<pid>/oom_adj and /proc/<pid>/oom_score_adj for.

You are right, but additional resources and complexity is required.

>> * Possibility of using it with pstore: This code could be extended to log additional buffers to persistent storage same way main (kmsg) log buffer is.
> pstorefs and friends?

pstore filesystem is used to access already stored kernel data (e.g. 
kmsg buffer). But does not provide mechanism of storing userspace memory.

>> * Use case of attaching file descriptor to stdout/stderr: Especially in early userspace.
> You can redirect these also in userspace.

True for that, but as I said in my first argument there is no 
possibility of logging process identification in case of sockets.


>> * Performance: Those services mentioned by You are weeker solutions in that case. Especially systemd-journald is much too heavy soulution.
> Do you have numbers? I agree systemd-journald is heavy wight. But it is by far not the only logging daemon we have...

I compared write operations on kmsg buffervia write/read operations on 
socketon SOCK_STREAM socket and sendmsg/recv on SOCK_DGRAM socket. 
Compared toSOCK_STREAM socket it was about 39% slowerbut compared 
toSOCK_DGRAM socket it was about 326% faster.syslogfor example uses 
SOCK_DGRAM sockets.In all cases there were 2^20 (1048576) write/sendmsg 
operations of 2^8 (256) bytes.

Best Regards,
Marcin Niesluchowski
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists