Message-ID: <b16efbf4-47ee-4689-debf-76ff7cf83903@redhat.com>
Date:   Tue, 3 Aug 2021 14:37:53 +0200
From:   Daniel Bristot de Oliveira <bristot@...hat.com>
To:     Thomas Gleixner <tglx@...utronix.de>,
        LKML <linux-kernel@...r.kernel.org>
Cc:     Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...nel.org>,
        Juri Lelli <juri.lelli@...hat.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Will Deacon <will@...nel.org>,
        Waiman Long <longman@...hat.com>,
        Boqun Feng <boqun.feng@...il.com>,
        Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
        Davidlohr Bueso <dave@...olabs.net>
Subject: Re: [patch 00/63] locking, sched: The PREEMPT-RT locking
 infrastructure

On 7/30/21 3:50 PM, Thomas Gleixner wrote:
> Folks,
> 
> the following series is an update to V1 which can be found here:
> 
>   https://lore.kernel.org/r/20210713151054.700719949@linutronix.de
> 
> It contains the bulk of the PREEMPT-RT locking infrastructure. In
> PREEMPT-RT enabled kernels the following locking primitives are substituted
> by RT-Mutex based variants:
> 
>   mutex, rw_semaphore, spinlock, rwlock
> 
> semaphores are not substituted because they do not provide strict owner
> semantics.
> 
> ww_mutexes are also not substituted because the usage sites are not really
> RT relevant and it would require a full reimplementation to make them work
> correctly based on rtmutex. That might change in the future, but for now
> utilizing the existing variant is considered a safe and sane choice.
> 
> Of course raw_spinlocks are not touched either as they protect low level
> operations in the scheduler, timers and hardware access.
> 
> The most interesting parts of the series which need a lot of eyeballs
> are:
> 
>   - the scheduler bits which provide the infrastructure for spinlock and
>     rwlock substitution to ensure that the task state is preserved when
>     blocking on such a lock and a regular wakeup is handled correctly and
>     not lost
> 
>   - the rtmutex core implementation to handle lock contention on spinlocks
>     and rwlocks correctly vs. the task state
> 
>   - the rw_semaphore/rwlock substitutions which utilize the same
>     implementation vs. the reader/writer handling
> 
>   - the isolation of the ww_mutex code which allows to build it stand alone.
>     The typedef based solution might look a bit odd on the first glance,
>     but that turned out to be the least intrusive variant.
> 
>   - the PI futex related bits to handle the interaction between blocking
>     on the underlying rtmutex and contention on the hash bucket lock which
>     is converted to a 'sleeping spinlock'.
> 
> The rest surely needs a thorough review as well, but those parts are pretty
> straight forward. Quite some code restructuring and the actual wrapper
> functions to replace the existing !RT implementations.
> 
> The series survived quite some internal testing in RT kernels and is part
> of the recent 5.14-rc3-rt2 release.
> 
> For !RT kernels there is no functional change.
> 
> The series is also available from git:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/tglx/devel.git rtmutex
> 
> and fully integrated into the v5.14-rc3-rt2 release:
> 
>  https://lore.kernel.org/r/20210730131256.7d3jccmpuiw5pr4o@linutronix.de

Thomas,

While reviewing/testing this series, I ended up finding some (simple) typos,
reporting them here:

patch 2:
	unneccesary -> unnecessary

patches 2/3/27/29/31:	
	accross -> across

patch 4:
	optimze -> optimize
	
patches 4/15:
	seperately -> separately

patches 5(2x)/12/17/18:
	seperate -> separate

patch 11:
	appropiate -> appropriate

patch 15:
	indentical -> identical

patch 34:
	Preperatory -> Preparatory

patch 53:
	completness -> 	completeness

patch 61:
	Signficant -> Significant

continuing the testing...

-- Daniel

Powered by blists - more mailing lists