Date: Mon, 01 Aug 2011 16:00:58 +0300 From: Andriy Gapon <avg@FreeBSD.org> To: arch@FreeBSD.org Subject: sketch of a design for lock-less and non-interleaved msgbuf Message-ID: <4E36A38A.20204@FreeBSD.org> In-Reply-To: <4DEE37C6.8070303@FreeBSD.org> References: <4DEE37C6.8070303@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Just so that it is not lost in /dev/null, maybe someone might find some useful bit in it. Please see in the forwarded message. -------- Original Message -------- Message-ID: <4DEE37C6.8070303@FreeBSD.org> Date: Tue, 07 Jun 2011 17:37:58 +0300 From: Andriy Gapon <avg@FreeBSD.org> To: gibbs@FreeBSD.org CC: Kenneth D. Merry <ken@FreeBSD.org> Subject: Re: svn commit: r222537 - in head/sys: kern sys References: <201105311729.p4VHTwrZ033296@svn.freebsd.org> <4DE5D72A.1020405@FreeBSD.org> <4DE66249.5070503@FreeBSD.org> In-Reply-To: <4DE66249.5070503@FreeBSD.org> on 01/06/2011 19:01 Justin T. Gibbs said the following: > On 6/1/11 12:07 AM, Andriy Gapon wrote: >> P.S. I have been thinking about fixing the problem in a different fashion, via >> reserving portions of dmesg buffer for a whole message using CAS: >> http://lists.freebsd.org/pipermail/freebsd-hackers/2010-April/031535.html > > This is actually where we started (although unfortunately independently > since neither Ken nor I saw your previous email). As you say in your > message form last April, integrating this type of strategy into the > message buffer code is problematic. You need to track the in-progress > writes (i.e. holes in the message buffer) so that only fully committed > data is printed. I'm sure this can be done with per-cpu data structures > and a heavy dose of atomic ops, but after an hour of discussion, we wound > up with a ton of complexity and little confidence our design was sound. I think that I have a solution for this. It's not trivial, of course, but is sufficiently straightforward. But I am not sure if it provides any advantage over the spinlock approach. Besides it's just for the message buffer and not for console printing. But, just in case, here is the description. We use a message buffer like today plus the CAS approach described above. Additionally we use another (smaller) buffer, which we can call a buffer of pointers or, more abstractly, a message queue. In principle this is the same as our message buffer, but instead of characters we put into it pointers to complete messages composed in the main message buffer. The pointers are appended to the message queue using atomic operations in exactly the same fashion as we currently add characters to the normal message buffer. So a consumer interested in complete messages should track the pointer buffer and get pointers to complete messages in the main message buffer. A consumer like a debugger may want to access the main message buffer directly to examine even incomplete messages, possibly intermixed with the previous contents in the case a wraparound of message buffer occurred at least once. BTW, this approach could remove a need for the temporary on-stack buffers enabled by PRINTF_BUFR_SIZE. -- Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4E36A38A.20204>