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 v3] rcu: Add a minimum time for marking boot as completed
Date:   Wed, 8 Mar 2023 07:09:42 -0800
Message-Id: <4069DA96-5E01-4E70-8A04-52543A43B3BC@joelfernandes.org>
References: <ZAijOO0vEiiDn+Ex@lothringen>
Cc:     linux-kernel@vger.kernel.org, Qiuxu Zhuo <qiuxu.zhuo@intel.com>,
        Lai Jiangshan <jiangshanlai@gmail.com>,
        linux-doc@vger.kernel.org, "Paul E. McKenney" <paulmck@kernel.org>,
        rcu@vger.kernel.org, urezki@gmail.com
In-Reply-To: <ZAijOO0vEiiDn+Ex@lothringen>
To:     Frederic Weisbecker <frederic@kernel.org>
Precedence: bulk


> On Mar 8, 2023, at 7:01 AM, Frederic Weisbecker <frederic@kernel.org> wrot=
e:
>=20
> =EF=BB=BFOn Wed, Mar 08, 2023 at 05:52:50AM -0800, Joel Fernandes wrote:
>> Just to add to previous reply:
>>=20
>> One thing to consider is that it is more of a performance improvement for=

>> booting in expedited mode to fallback to normal later, than a bug
>> fix. Repeated synchronize_rcu() can easily add 100s of milliseconds and t=
o
>> remedy that =E2=80=94 a conversion of the call from normal API to the exp=
edited API
>> will not help.
>=20
> 2 things to consider:
>=20
> 1) Is it this about specific calls to synchronize_rcu() that repeat a lot
>   and thus create such measurable impact? If so the specific callsites sho=
uld
>   be considered for a conversion.
>=20
> 2) Is it about lots of different calls to synchronize_rcu() that gather a b=
ig
>   noise? Then the solution is different.
>=20
> Again without proper analysis, what do we know?

Again, no one disputed that proper analysis is needed. That is obvious. I wa=
s just responding to your assumption that if boot is slow, user space will a=
lso be slow. That is not a good thing to conclude because there are many fac=
tors. Slowness at boot may be considered a bug, but slowness after boot may n=
ot be (say if the user care mores for power later).

On my side I am planning to dig deeper into our boot process, but it will ta=
ke time. I hope Qiuxu can do the boot analysis on his side.

Thanks.

>=20
> Thanks.