Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   John Ogness <john.ogness@linutronix.de>
To:     Petr Mladek <pmladek@suse.com>
Cc:     linux-kernel@vger.kernel.org,
        Peter Zijlstra <peterz@infradead.org>,
        Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
        Steven Rostedt <rostedt@goodmis.org>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Andrea Parri <andrea.parri@amarulasolutions.com>,
        Thomas Gleixner <tglx@linutronix.de>,
        Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Subject: Re: [RFC PATCH v2 1/2] printk-rb: add a new printk ringbuffer implementation
References: <20190607162349.18199-1-john.ogness@linutronix.de>
        <20190607162349.18199-2-john.ogness@linutronix.de>
        <20190621140516.h36g4in26pe3rmly@pathway.suse.cz>
        <87d0j31iyc.fsf@linutronix.de>
        <20190624140948.l7ekcmz5ser3zfr2@pathway.suse.cz>
        <87blylhjy8.fsf@linutronix.de>
        <20190626082935.ocbqqaol5jzcuxwl@pathway.suse.cz>
Date:   Wed, 26 Jun 2019 11:09:26 +0200
In-Reply-To: <20190626082935.ocbqqaol5jzcuxwl@pathway.suse.cz> (Petr Mladek's
        message of "Wed, 26 Jun 2019 10:29:35 +0200")
Message-ID: <87pnn0yapl.fsf@linutronix.de>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On 2019-06-26, Petr Mladek <pmladek@suse.com> wrote:
>> To address your question: For the linked list implementation, if you
>> are looking at it from the linked list perspective, the number of
>> descriptors on the list is constantly fluctuating (increasing and
>> decreasing) and the ordering of the descriptors is constantly
>> changing. They are ordered according to the writer commit order (not
>> the writer reserve order) and the only descriptors on the list are
>> the ones that are not within a reserve/commit window.
>
> This and few other comments below are really valuable explanation.
> I misunderstood how the list worked.

I will add a documentation section about why a linked list was used.

>>>>> If the above is true then we could achieve similar result
>>>>> when using the array as a circular buffer. It would be
>>>>> the same like when all members are linked from the beginning.
>>>> 
>>>> So you are suggesting using a multi-reader multi-writer lockless
>>>> ringbuffer to implement a multi-reader multi-writer lockless
>>>> ringbuffer. ;-)
>>>> 
>>>> The descriptor ringbuffer has fixed-size items, which simplifies
>>>> the task. But I expect you will run into a chicken-egg scenario.
>>>
>>> AFAIK, the main obstacle with the fully lockless solution was
>>> that the entries did not have a fixed size.
>> 
>> No. The variable size of the records was the reason I used
>> descriptors. That has nothing to do with how I chose to connect those
>> descriptors.
>
> I think that we are talking about the same. If I remember correctly,
> the main problem is that cmpxchg() is not reliable when the same
> address might be used by the metadata and data.

The cmpxchg() issue you mention is why I needed descriptors. But even if
I were to implement a fixed-record-size ringbuffer where the cmpxchg()
issue does not exist, I _still_ would have used a linked list to connect
the records.

It is misleading to think the linked list is because of variable size
records.

John Ogness