Date: Fri, 17 Feb 2012 01:07:26 -0800 From: Julian Elischer <julian@freebsd.org> To: Pawel Jakub Dawidek <pjd@freebsd.org> Cc: marcel@freebsd.org, Eitan Adler <eadler@freebsd.org>, svn-src-all@freebsd.org, "Kenneth D. Merry" <ken@freebsd.org>, Andriy Gapon <avg@freebsd.org>, Marcel Moolenaar <marcel@xcllnt.net>, src-committers@freebsd.org, Bruce Evans <brde@optusnet.com.au>, svn-src-head@freebsd.org Subject: Re: svn commit: r231814 - in head/sys: kern sys Message-ID: <4F3E18CE.1010700@freebsd.org> In-Reply-To: <20120217085840.GC1358@garage.freebsd.pl> References: <201202160511.q1G5BZNk099785@svn.freebsd.org> <20120216181210.K1423@besplex.bde.org> <4F3CC40D.4000307@freebsd.org> <4F3CC5C4.7020501@FreeBSD.org> <4F3CC8A5.3030107@FreeBSD.org> <20120216174758.GA64180@nargothrond.kdm.org> <20120217053341.R1256@besplex.bde.org> <20120217000846.GA7641@nargothrond.kdm.org> <4F3D9D03.6020507@FreeBSD.org> <9CB7ECE8-FF10-43BE-9EBD-16953BE3B193@xcllnt.net> <20120217085840.GC1358@garage.freebsd.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2/17/12 12:58 AM, Pawel Jakub Dawidek wrote:
> On Thu, Feb 16, 2012 at 08:49:05PM -0800, Marcel Moolenaar wrote:
>> On Feb 16, 2012, at 4:19 PM, Andriy Gapon wrote:
>>
>>> on 17/02/2012 02:08 Kenneth D. Merry said the following:
>>> [snip]
>>>>>> On Thu, Feb 16, 2012 at 11:13:09 +0200, Andriy Gapon wrote:
>>> [snip]
>>>>>>> For me personally the immediate benefits in the common situations
>>>>>>> outweighed the
>>>>>>> problems in the edge cases, although I still believe that we can get the
>>>>>>> former
>>>>>>> without sacrifices in the latter.
>>> [snip]
>>>> It sounds fine, but I don't have sufficient time to spend on this right
>>>> now. So I can either back out the changes I mentioned above (assuming we
>>>> get agreement from avg), or leave things as is.
>>> I stick to what I wrote above and so chose the status quo.
>>> The backout would make sense if it is immediately followed by commit of a better
>>> solution. Unfortunately, a lack of time here too.
>> I think we should lift above the immediate problem and allow for
>> single- and multi-line messages that are atomically appended to
>> the message buffer. Console output and propagation of messages
>> outside of the kernel should all come out of the message buffer
>> and preserving the atomicity of the messages.
>>
>> The message buffer does not have to be a chunk of memory that
>> we circularly scribble to. It can be a per-cpu linked list of
>> messages even.
>>
>> The advantage of thinking along these lines is that:
>> 1. Console output can be made optional very easily, allowing
>> us to implement quiet boots without loosing the ability
>> to look at messages collected during boot.
>> 2. Atomicity allows us to parse the messages reliably, which
>> works very well in the embedded space where monitoring of
>> kernel messages is common.
>> 3. You can decouple writing into the message buffer from
>> extracting messages out of the message buffer, allowing
>> the low-level console to become just another channel to
>> send messages to, rather than be fundamental for printf.
>> 4. A linked list (for example) eliminates the problem of
>> scribbling over old messages and possibly leaving partial
>> output that gets misinterpreted.
>> 5. A per-cpu message buffer eliminates serialization to
>> guarantee atomcity and with timestamping can very easily
>> be turned into a sequential log.
>> 6. We haven't introduced complications (e.g. locking) to
>> solve these problems and that make using printf in low-
>> level code impossible. Thank trap handlers or interrupt
>> handlers.
> I agree with everything except for per-CPU buffers. I understand the
> need for using printf in low-level code and it indeed complicates things.
> The reason I don't like the idea of per-CPU buffers is that locking
> would allow me to implement atomicity across multiple printfs.
> For example I often use macros like this:
>
> #define G_MIRROR_DEBUG(lvl, ...) do { \
> if (g_mirror_debug>= (lvl)) { \
> printf("GEOM_MIRROR"); \
> if (g_mirror_debug> 0) \
> printf("[%u]", lvl); \
> printf(": "); \
> printf(__VA_ARGS__); \
> printf("\n"); \
> } \
> } while (0)
>
> And I'd like all the printfs to be committed as one message without
> using some additional buffer first and then single printf.
> With some kind of printf-lock we could use recursive locking to achieve
> this. In your proposal I may run each printf on different CPU.
> I could eventually use sched_pin() around all printfs, I guess.
> This still doesn't cover the case when I'm preempted between my printfs,
> so maybe I need critical section there? I don't expect printf should be
> fast, so it might be ok.
with locking your example could still be broken up because there is a
lock per printf..
if you want them done together you really should print parts to a
separate assembly buffer and then put it all out at once.
I actually like the idea of pcpu buffers. witha single atomic sequence
number being the only
sychroniaation needed.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4F3E18CE.1010700>