Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From:   Joel Fernandes <joel@joelfernandes.org>
Mime-Version: 1.0 (1.0)
Subject: Re: [PATCH v2 1/2] locktorture: Allow non-rtmutex lock types to be boosted
Date:   Thu, 8 Dec 2022 22:58:36 -0500
Message-Id: <2D7B1E52-D2FC-45ED-A739-BA9A1213FD49@joelfernandes.org>
References: <20221209032550.p4tcyypgkuspp2ur@offworld>
Cc:     linux-kernel@vger.kernel.org,
        Josh Triplett <josh@joshtriplett.org>,
        "Paul E. McKenney" <paulmck@kernel.org>, rcu@vger.kernel.org,
        connoro@google.com
In-Reply-To: <20221209032550.p4tcyypgkuspp2ur@offworld>
To:     Davidlohr Bueso <dave@stgolabs.net>
Precedence: bulk


> On Dec 8, 2022, at 10:50 PM, Davidlohr Bueso <dave@stgolabs.net> wrote:
>=20
> =EF=BB=BFOn Fri, 09 Dec 2022, Joel Fernandes (Google) wrote:
>=20
>> Currently RT boosting is only done for rtmutex_lock, however with proxy
>> execution, we also have the mutex_lock participating in priorities. To
>> exercise the testing better, add RT boosting to other lock testing types
>> as well, using a new knob (rt_boost).
>=20
> No particular objection to the patches, but shouldn't these go as part
> of the next iteration of the PE series?

Hey Davidlohr,
Nice to hear from you. Paul was interested in these for some things he is lo=
oking at and also as general clean up ;)

Thanks.


>=20
> Thanks,
> Davidlohr